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
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