[Gc] GC 6.4 simplified leak detection breaks on SuSE Linux 9.3 i386(glibc 2.3.4)

Boehm, Hans hans.boehm at hp.com
Thu May 12 18:27:14 PDT 2005


Thanks for the bug report.

I attached a completely untested patch.  The intent is to
break the recursion in GC_in_save_callers, where it's only
somewhat performance critical.  Could you let me know
if this works (or what you needed to change to make it
compile/work :-) )

Thanks.

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Matthias Andree
> Sent: Sunday, May 08, 2005 9:07 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] GC 6.4 simplified leak detection breaks on SuSE 
> Linux 9.3 i386(glibc 2.3.4)
> 
> 
> [resending this after subscribing myself -- please discard 
> the moderated post]
> 
> Greetings,
> 
> I have used GC 6.4 successfully as a pretty accurate leak 
> detector on SuSE Linux 9.2 i386, with the 
> LD_PRELOAD=/usr/local/lib/libgc.so.1 scheme.
> 
> I compiled GC 6.4 after running configure like this: 
> ./configure --disable-threads --enable-redirect-malloc 
> --enable-full-debug
> 
> With SuSE Linux 9.3 however, this causes a segmentation fault 
> and drops core - this looks like a stack overflow to me. 
> Recompiling GC6.4 didn't help.
> 
> SuSE 9.2 used glibc-2.3.3-118
> SuSE 9.3 uses glibc-2.3.4-23
> 
> A stack backtrace from the core file ends like shown below 
> (outermost frames), it is recursing on #45402...#45414.
> 
> I read this as though the malloc redirection would cause 
> bogus results. What a pity - this "simplified leak detection" 
> is SO convenient.
> 
> Don't ask me what business backtrace() has with passwd lookup.
> 
> My current trial & error idea to fix this is to add a marker 
> in GC_debug_malloc that prevents recursion of this function - 
> but how would this work for threaded programs? Other ideas 
> how to fix this?
> 
> Thanks in advance.
> 
> Regards,
> Matthias Andree
> 
> #45402 0xb7fd36c0 in GC_save_callers (info=0x805af60) at 
> os_dep.c:3999 #45403 0xb7fcb540 in GC_debug_malloc (lb=19, 
> s=0xb7fd81f6 "unknown", i=0)
>     at dbg_mlc.c:502
> #45404 0xb7fce264 in malloc (lb=19) at malloc.c:349
> #45405 0xb7ff14d2 in _dl_rtld_di_serinfo () from 
> /lib/ld-linux.so.2 #45406 0xb7f451ce in _dl_open () from 
> /lib/tls/libc.so.6 #45407 0xb7ff7186 in _dl_rtld_di_serinfo 
> () from /lib/ld-linux.so.2 #45408 0xb7f44b70 in _dl_open () 
> from /lib/tls/libc.so.6 #45409 0xb7f46cdd in 
> __libc_dlopen_mode () from /lib/tls/libc.so.6 #45410 
> 0xb7ff7186 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 
> #45411 0xb7f46b65 in _dl_mcount_wrapper () from 
> /lib/tls/libc.so.6 #45412 0xb7f46c8b in __libc_dlopen_mode () 
> from /lib/tls/libc.so.6 #45413 0xb7f2434a in 
> __nss_passwd_lookup () from /lib/tls/libc.so.6 #45414 
> 0xb7f244e7 in backtrace () from /lib/tls/libc.so.6 #45415 
> 0xb7fd36c0 in GC_save_callers (info=0x805afb0) at 
> os_dep.c:3999 #45416 0xb7fcb540 in GC_debug_malloc (lb=19, 
> s=0xb7fd81f6 "unknown", i=0)
>     at dbg_mlc.c:502
> #45417 0xb7fce264 in malloc (lb=19) at malloc.c:349
> #45418 0xb7ff14d2 in _dl_rtld_di_serinfo () from 
> /lib/ld-linux.so.2 #45419 0xb7f451ce in _dl_open () from 
> /lib/tls/libc.so.6 #45420 0xb7ff7186 in _dl_rtld_di_serinfo 
> () from /lib/ld-linux.so.2 #45421 0xb7f44b70 in _dl_open () 
> from /lib/tls/libc.so.6 #45422 0xb7f46cdd in 
> __libc_dlopen_mode () from /lib/tls/libc.so.6 #45423 
> 0xb7ff7186 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 
> #45424 0xb7f46b65 in _dl_mcount_wrapper () from 
> /lib/tls/libc.so.6 #45425 0xb7f46c8b in __libc_dlopen_mode () 
> from /lib/tls/libc.so.6 #45426 0xb7f2434a in 
> __nss_passwd_lookup () from /lib/tls/libc.so.6 #45427 
> 0xb7f244e7 in backtrace () from /lib/tls/libc.so.6 #45428 
> 0xb7fd36c0 in GC_save_callers (info=0xb7fe9014) at 
> os_dep.c:3999 #45429 0xb7fc9a7e in GC_try_to_collect_inner (
>     stop_func=0xb7fc8d70 <GC_never_stop_func>) at alloc.c:363 
> #45430 0xb7fd27a3 in GC_init_inner () at misc.c:782 #45431 
> 0xb7fce505 in GC_generic_malloc_inner (lb=101, k=1) at 
> malloc.c:160 #45432 0xb7fce59d in GC_generic_malloc (lb=101, 
> k=1) at malloc.c:192 #45433 0xb7fce700 in GC_malloc (lb=101) 
> at malloc.c:311 #45434 0xb7fcb51f in GC_debug_malloc (lb=42, 
> s=0xb7fd81f6 "unknown", i=0)
>     at dbg_mlc.c:490
> #45435 0xb7fce264 in malloc (lb=42) at malloc.c:349
> #45436 0x08048440 in main () at leakmem.c:16 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com 
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: os_dep.c.diff
Type: application/octet-stream
Size: 1359 bytes
Desc: os_dep.c.diff
Url : http://napali.hpl.hp.com/pipermail/gc/attachments/20050512/b323d59d/os_dep.c-0001.obj


More information about the Gc mailing list