I'm starting to think this might not be a real memory leak, but rather an artifact of how the taskmanager is reporting the working set size. I'm seeing the same behavior you do of it stabilizing around 13Mb. I was able to selectively comment out bits to reduce it down to a small window that still shows the memory increase behavior. Essentially, you see this if you do nothing more than create an interpreter instance and then destroy it. This window of code is sort of "irreducibly complex"....I've not had much success in shrinking this any further and have traced through the entire path length looking for potential leaks and have come up empty.
What I think is happening here is each iteration allocates a bunch of objects from the object heap, but ends up touching additional bits of the heap on each iteration until it has managed to mark across the entire initial heap space, then things settle down. At no point during this process is any additional memory getting allocated, but Windows is committing sections of the first time the memory is actually referenced. So using the task manager, it appears that memory is climbing, but that storage is fully usable and is garbage collected appropriately. I believe we had something like this happen once before. Rick On Mon, Jul 6, 2009 at 4:02 PM, Mark Miesfeld<miesf...@gmail.com> wrote: > On Mon, Jul 6, 2009 at 11:05 AM, Rick McGuire<object.r...@gmail.com> wrote: > >> Ok, I think this problem might need a different pair of eyes looking >> at it or a different approach. I figured out where the handle leak is >> coming from and fixed that problem, but there is a memory leak of >> about 24-32Kb per call to RexxStart() that's got me completely > > Don't know if this will mean anything to you. > > For just a quick test, in the CvHello.cpp example sent by the bug > opener, I added the > > #define _CRTDBG_MAP_ALLOC > #include <stdlib.h> > #include <crtdbg.h> > > And recompiled CvHello.exe as debug. When I run the program in the > debugger, after about 200 (150 ?) iterations, the memory stops > increasing. It hits 13,480 K on my system and then stays there. > > > Then after about another 5 minutes, another 200 iterations maybe, the > debugger breaks in with this statement: > > Run-time Check Failure #2 - Stack aroung the variable 'strParam' was > corrupted. > > I ran it twice and got the same thing. > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
