Unhandled Exception: Unhandled Memory Exception Er
BlitzMax Forums/BlitzMax Programming/Unhandled Exception: Unhandled Memory Exception Er
| ||
| Hello folks, I know that this topic has been covered somewhat in the past (http://blitzmax.com/Community/posts.php?topic=48556), but I wanted to chime in with my own experience on the matter. I'm having trouble using FlushMem(). Whenever I try to use it in my main loop, it succeeds -once- and then crashes with "Unhandled Exception: Unhandled Memory Exception Error" (in windows) or an "app unexpectedly quit" (in OS X) error. Whenever I try to call it "between levels" (that is, I restrict its use to once every minute or so) it works properly for a few times, then my variables start to become corrupted. (This 'decay' seems to be affected both by number of times I call FlushMem and the total runtime of the app; if I let a single level run for a few minutes, it begins to corrupt my variables without having called FlushMem a second time.) I do not call FlushMem() from within any functions or methods; I only use it at the root level of my application. I'd post code, but my app is currently a jungle of ~5500 lines spread across 20 or so files, and I haven't been able to pin down any real culprit for this behavior. I've eliminated array-slicing by using the workaround in the above thread, but the problems persist. To give you an idea of how this is working, I have a bare handful of global variables and functions and a single instance of a "universe" user-defined object, which contains all my levels, player data, game objects, graphics initialization routines, loading routines, parsing routines, drawing routines--pretty much everything I do happens within the "universe" object. I have a number of user-defined types, and I cross-link them fairly heavily. There are a few cyclic links, but I've taken pains to ensure that these cyclic links are de-referencing before deletion; in any case, failure to do so should result in a memory leak (as opposed to an outright crash.) Any ideas as to what may be going on here? Again, I apologise for not being able to produce example code; as soon as I've narrowed down some kind of culprit, I'll post more... Tom |
| ||
| Are you using strict? (should be done in any case as variable scope work different if not) Perhaps you flushmem away local variables that your functions and methods still base on and where they run in null references. Especially as you say that you are manually killing references as well ... With debug enabled, the line where the error appears should be more or less be shown (+- 1 line) and you should be able to pin the error down or at least find a hint where to start your error search. |
| ||
| Hi Tom, I don't think that cyclic links are the cause of the problem, but a strongly suggest that you try and remove them. These kind of bugs can be very difficult to pinpoint, the only option is usually to disable as much as possible, that re-enable the various parts of the game until the problem shows up again. |
| ||
| With debug mode on, is it crashing on the FlushMem line, or highlighting other lines? |
| ||
| Sorry for digging out this post, however i have the same problem. This do not happen with every app, just with a special one. The app runs fine, but after including this one type the whole app crashes. I don't know if it is wise to post 500 lines of code, from the code i believe the bug must be there. No error during creation of the single objects, no error during update, draw, create functions, just the first call of flushmem in the mainloop leads the programm to an UMEE. The problem occurs first after the 1.10 update. I am sure this isn't a thing of nullobject reference. I really don't know how to solv this one. The DebugLog, right after error, is this one: - Function Delete - Local Self:TDX7ImageFrame=$02E65B20 Type TDX7ImageFrame Field driver:TD3D7Max2DDriver=$003D3D88 Field surface?IDirectDrawSurface7=@$32dc800 Field sinfo:DDSurfaceDesc2=$02E65BB0 Field xyzuv#[]=[...] Field width=11 Field height=10 Field flags=9 Field seq=2 Maybe you'll discover some bugs from this DebugLog. I hope so. After error the online line which is highlighted is the flushmem() line. |
| ||
| regaa / Tom, feel free to email me your programs so I can reproduce the problem here. |
   |