[Gc] GC 6.4 simplified leak detection breaks on SuSE Linux9.3i386(glibc 2.3.4)

Boehm, Hans hans.boehm at hp.com
Tue May 17 15:27:51 PDT 2005


Thanks.

I've attached the alloc.c patch I ended up putting in my tree.  Please
let
me know if you see any problems.

Hans

> -----Original Message-----
> From: Matthias Andree [mailto:matthias.andree at gmx.de] 
> Sent: Tuesday, May 17, 2005 2:18 AM
> To: gc at linux.hpl.hp.com
> Cc: Boehm, Hans
> Subject: Re: [Gc] GC 6.4 simplified leak detection breaks on 
> SuSE Linux9.3i386(glibc 2.3.4)
> 
> 
> On Mon, 16 May 2005, Hans Boehm wrote:
> 
> > It looks like the GC initialization routine is being called 
> > recursively, because the initialization routine forces a GC (around 
> > line 782, misc.c) just before setting the GC_is_initialized flag.  
> > That unfortunately again generates a backtrace, which 
> allocates, which 
> > invokes the GC, which restarts the initialization.
> > 
> > Can you try commenting out the three calls to GC_save_callers in 
> > alloc.c?  They're really only needed for GC debugging, I 
> believe. If 
> > that solves the problem, we can conditionally take them out. (I'm 
> > pretty sure this will help.  I'm less sure this is the last such 
> > problem.)
> 
> Now we're getting somewhere :-)
> 
> My simple test program (attached) worked with gc6.4 with
> 
> #1 the patch you posted earlier,
> #2 the return inserted into the if (GC_in_save_callers) {} 
> block #3 the three GC_save_callers in alloc.c masked by #if 0
> 
> and produced this:
> 
> got 0x805af88
> got 0x805af18
> Leaked composite object at 0x805af88 (unknown:0, sz=42, NORMAL)
>         Call chain at allocation:
>                 
> /tmp/gc6.4/.libs/libgc.so(GC_debug_malloc+0xac) [0xb7fc8aeb]
>                 /tmp/gc6.4/.libs/libgc.so(malloc+0x27) [0xb7fcc6b3]
>                 main:../../../src/tests/leakmem.c:17 [0x8048440]
> 
> which is the expected output.
> 
> There still seems to be something problematic going on 
> though, but it may be an unsupported configuration since it 
> affects a program that might be using Berkeley DB 4.3, and 
> this might in turn pull in libpthread for futex support, and 
> AFAICS this "simplified leak detection" isn't even supposed 
> to work with threads.
> 
> I don't have time to debug this now or provide detailed info, 
> more later if I can reproduce the problem.
> 
> Thanks so far.
> 
> -- 
> Matthias Andree
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alloc.c.diff
Type: application/octet-stream
Size: 1605 bytes
Desc: alloc.c.diff
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20050517/59fb18d6/alloc.c.obj


More information about the Gc mailing list