[Gc] Leaking Boehm GC on CE 6

[DrPizza]

I thought WinCE 6 totally changed the memory map, going from the awful 32 by 32 MB slot with the rest shared architecture of previous WinCE to a proper 2/2 GB split protected memory system.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com [mailto:gc-
> bounces at napali.hpl.hp.com] On Behalf Of Craig Vanderborgh
> Sent: 12 January 2009 05:12
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Leaking Boehm GC on CE 6
> 
> Hello!
> 
> Many years ago (back in 2003 to be exact) Hans Boehm and others helped
> us get Boehm-GC working correctly on gcj 3.3 on arm-wince-pe (Windows
> CE 3.0, at that time).  Everything - particularly that modified-for-CE
> build of Boehm GC - has been working extremely well until recently.
> We are extremely grateful for both the help we received then and the
> reliable and performant operation that Boehm GC has delivered over the
> years.
> 
> Then along came Windows CE 6.  gcj/boehm still work without crashing,
> but on CE 6 we are experiencing severe leaking.  Specifically: a gcj
> binary that works perfectly (without leaking) on Windows CE 4/5
> exhibits fairly large memory leaks when run on CE 6.
> 
> This is baffling to say the very least.  As far as I can tell, the
> memory map on Windows CE 6 is the same and I'm not aware of any reason
> WHY the Boehm GC would leak on CE 6 when it does not on other earlier
> versions.
> 
> I am gearing up for what I expect will be a long and difficult project
> to find and fix this problem.  I need some ideas about where I could
> look for the problem, and some idea of whether there might be fixes
> for the GC in versions after 6.2 that might be relevant.  I have
> ported the "test.c" that's used to build gctest to arm-wince-pe
> (GNUWINCE), and here is the output from gctest.exe on Windows Mobile 5
> (no leaking):
> 
> Completed 1 tests
> Allocated 560621 collectable objects
> Allocated 101 uncollectable objects
> Allocated 1250000 atomic objects
> Allocated 11480 stubborn objects
> Finalized 2206/2206 objects - finalization is probably ok
> Total number of bytes allocated is 59998108
> Final heap size is 3739648 bytes
> Collector appears to work
> 
> Whereas the same gctest.exe binary run on CE 6 produces the following:
> 
> Completed 1 tests
> Allocated 560621 collectable objects
> Allocated 101 uncollectable objects
> Allocated 1250000 atomic objects
> Allocated 11480 stubborn objects
> Finalized 1931/2206 objects - finalization is probably ok
> Total number of bytes allocated is 59998108
> Final heap size is 11591680 bytes
> Unexpected heap growth - collector may be broken
> Collector appears to work
> 
> Thus even the fairly simple standard "gctest.exe" exhibits the
> problem: not all allocated objects have been finalized - presumably
> because they were not identified during the mark phase.
> 
> It's early days on this effort, but right now I am adrift.  Any
> guidance or suggestions on how to proceed would be greatly
> appreciated.
> 
> Thanks in advance!
> Craig Vanderborgh
> Voxware Incorporated
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/