[Gc] Large block uncollected ?
ktreichel at web.de
Mon Aug 11 08:54:52 PDT 2008
Am Montag, den 11.08.2008, 17:14 +0200 schrieb Nicolas Cannasse:
> 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.
> Gc mailing list
> Gc at linux.hpl.hp.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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