[Gc] Large block uncollected ?

Klaus Treichel ktreichel at web.de
Mon Aug 11 08:54:52 PDT 2008

Hi Nicolas,

Am Montag, den 11.08.2008, 17:14 +0200 schrieb Nicolas Cannasse:
> Hello,
> In our multithread server, we noticed that we were having some kind of 
> GC'ed memory leaks. One part might be due to fragmentation but given the 
> amount of leaked memory, it can't be the only explanation.
> I was thinking that maybe some pointers were staying on the C stack so I 
> tried to stop the threads after some time and start another one. It was 
> not very successful as well.
> Actually, even after all threads were stopped, some large blocks were 
> still listed in the used blocks in GC_dump().
> I could reproduce the problem is a standalone example :
> There is a block of 2MB allocated at 0x00B90000 (+0x10 for debug infos) 
> using GC_MALLOC_ATOMIC. In GC_push_current_stack, the address 0x00CCCCCC 
> is found, which is inside the block, but should not be valid.
> It turns out that in GC_mark_and_push_stack, GC_base is called, which 
> returns the header of 0x00B90000. Is there a way to disable this 
> behavior ? I don't need to GC to check for any kind of displacement.

In this case you should try GC_MALLOC_ATOMIC_IGNORE_OFF_PAGE instead.


> Best,
> Nicolas
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : https://napali.hpl.hp.com/pipermail/gc/attachments/20080811/4b642945/attachment.pgp

More information about the Gc mailing list