[Gc] Internal memory leak for small objects

Boehm, Hans hans.boehm at hp.com
Mon Dec 1 16:41:33 PST 2008


Oops.  Another bug that snuck in around 7.0.  The collector was dropping some objects that it decided were too expensive to reclaim.  That's a fine strategy, but not with GC_find_leak set ...

Thanks for the nice test case.

Fixed in CVS. See http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/reclaim.c?r1=1.8&r2=1.9 .

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Friday, November 28, 2008 6:27 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Internal memory leak for small objects
>
> Hi!
>
> Consider this test app:
>
> #include <stdio.h>
> #include "gc.h"
>
> void *ptr = 0;
> int main(void)
> {
>   int j;
>   GC_INIT();
>   for (j = 60; j < 90; ++j) {
>     void **p = GC_MALLOC(j*sizeof(void*));
>     printf("%p\n",p);
>     *p = ptr;
>     ptr = p;
>     GC_gcollect();
>   }
>   return 0;
> }
>
> The GC lib is built in config -DFIND_LEAK
> -DALL_INTERIOR_POINTERS (for simplicity). The test is
> compiled without any options. Here I use VC++ but the bug is
> platform-independent.
>
> Running this test gives:
> 00180E88
> 00180D90
> 00181F00
> 00181E00
> 00182E40
> 00182D10
> 00182BE0
> 00182AB0
> 00182980
> 00182850
> 00182720
> 001825F0
> 001824C0
> 00182390
> 00182260
> 00182130
> 00183E60
> 00183CF0
> 00183B80
> 00183A10
> 001838A0
> 00183730
> 001835C0
> 00183450
> 001832E0
> 00183170
> 00184E60
> 00183000
> 00184CF0
> 00184B80
>
> Log file contains:
> Leaked composite object at start: 00182000, appr. length: 304
> Leaked composite object at start: 00182000, appr. length: 304
> Leaked composite object at start: 00182000, appr. length: 304
> Leaked composite object at start: 00182000, appr. length: 304
> Leaked composite object at start: 00182000, appr. length: 304
> Leaked composite object at start: 00183000, appr. length: 368
> Leaked composite object at start: 00182000, appr. length: 304
> Leaked composite object at start: 00182000, appr. length: 304
>
> You can see that leaked object is:
> 1. SMALL_OBJ;
> 2. never returned by GC_malloc.
>
> I don't know whether the bug is specific to FIND_LEAK mode or not.
> In fact, this object is removed from GC_obj_kinds list by
> GC_start_reclaim(FALSE) instead of being reconstructed. I'm
> failed to find out more...
>
> Bye.
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>



More information about the Gc mailing list