[Gc] "Leaked composite object at", but the object was never allocated

Benjamin Smedberg bsmedberg at mozilla.com
Thu Sep 25 11:54:30 PDT 2008


Benjamin Smedberg wrote:

> Fairly early in startup, I think during the first GC, Boehm reports a bunch
> of leaked objects of size 32. I tried turning on GC_DEBUG stack traces, but

> Any clues? Perhaps I can watch the header block associated with this
> allocation to find out when it's being set up?

I did this and found the allocation location!

#0  setup_header (hhdr=0x807d010, block=0x808c000, byte_sz=32, kind=2, flags=0)
    at ../../../src/memory/boehmgc/allchblk.c:233
#1  0xf7fca5d4 in GC_allochblk_nth (sz=32, kind=2, flags=0, n=16, may_split=1)
    at ../../../src/memory/boehmgc/allchblk.c:791
#2  0xf7fca799 in GC_allochblk (sz=32, kind=2, flags=0) at
../../../src/memory/boehmgc/allchblk.c:628
#3  0xf7fd8790 in GC_new_hblk (gran=4, kind=2) at
../../../src/memory/boehmgc/new_hblk.c:190
#4  0xf7fcc0d0 in GC_allocobj (gran=4, kind=2) at
../../../src/memory/boehmgc/alloc.c:1055
#5  0xf7fd206b in GC_generic_malloc_inner (lb=27, k=2) at
../../../src/memory/boehmgc/malloc.c:119
#6  0xf7fd210a in GC_generic_malloc (lb=27, k=2) at
../../../src/memory/boehmgc/malloc.c:159
#7  0xf7fd2c7f in GC_malloc_uncollectable (lb=27) at
../../../src/memory/boehmgc/mallocx.c:466
#8  0xf7fd1bdd in malloc (lb=28) at ../../../src/memory/boehmgc/malloc.c:319
#9  0x00269dd3 in _dl_map_object_deps () from /lib/ld-linux.so.2
#10 0x0026eecd in dl_open_worker () from /lib/ld-linux.so.2
#11 0x0026b1b6 in _dl_catch_error () from /lib/ld-linux.so.2
#12 0x0026e852 in _dl_open () from /lib/ld-linux.so.2
#13 0x003865d2 in do_dlopen () from /lib/libc.so.6
#14 0x0026b1b6 in _dl_catch_error () from /lib/ld-linux.so.2
#15 0x00386785 in __libc_dlopen_mode () from /lib/libc.so.6
#16 0x00362e89 in init () from /lib/libc.so.6
#17 0x003e89e0 in pthread_once () from /lib/libpthread.so.0
#18 0x00363065 in backtrace () from /lib/libc.so.6
#19 0xf7fd9004 in GC_save_callers (info=0xf7ffc54c) at
../../../src/memory/boehmgc/os_dep.c:4105
#20 0xf7fcb85b in GC_try_to_collect_inner (stop_func=0xf7fca840
<GC_never_stop_func>)
    at ../../../src/memory/boehmgc/alloc.c:359
#21 0xf7fd819a in GC_init_inner () at ../../../src/memory/boehmgc/misc.c:735
#22 0xf7fd2035 in GC_generic_malloc_inner (lb=351, k=2) at
../../../src/memory/boehmgc/malloc.c:112
#23 0xf7fd210a in GC_generic_malloc (lb=351, k=2) at
../../../src/memory/boehmgc/malloc.c:159
#24 0xf7fd2c7f in GC_malloc_uncollectable (lb=351) at
../../../src/memory/boehmgc/mallocx.c:466
#25 0xf7fd1bdd in malloc (lb=352) at ../../../src/memory/boehmgc/malloc.c:319
#26 0x002d4cef in __fopen_internal () from /lib/libc.so.6
#27 0x002d72cc in fopen64 () from /lib/libc.so.6
#28 0x0069b234 in ?? () from /lib/libselinux.so.1
#29 0x0069d136 in ?? () from /lib/libselinux.so.1
#30 0x00278fc0 in ?? () from /lib/ld-linux.so.2
#31 0xf7bb59e0 in ?? ()
#32 0xffede1c8 in ?? ()
#33 0x0068d2b1 in _init () from /lib/libselinux.so.1

The bug seems to be that Boehm is calling backtrace from within the
allocation lock (frame 19->18), and doesn't expect backtrace to re-enter.
When it does re-enter, the heap structure is in an inconsistent state.

--BDS


More information about the Gc mailing list