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

Benjamin Smedberg benjamin at smedbergs.us
Thu Sep 25 07:47:08 PDT 2008

Hash: SHA1

In my ongoing project attempting to use Boehm GC in Mozilla, I wanted to
make sure that Boehm was scanning our memory correctly and that we weren't
hiding any pointers unintentionally: so I hooked up Boehm in leak-detector mode.

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
this object didn't have any debugging information (allocation stacktrace)
recorded. So I went through and tried to find the allocation site using a

Leaked composite object at 0x808c020
Leaked composite object at 0x808c040
Leaked composite object at 0x808c060
Leaked composite object at 0x808c080
... all the way to 0x808c220

I tried breakpoing GC_allocobj, GC_generic_malloc_inner and several other
functions, but none of these functions ever return an allocation at
0x808c020. In fact, the very first allocation returned is at 0x808dfe0.

I'm worried that Boehm is reporting a leak for an object that never seems to
have been allocated in the first place. So I went back and found where this
address space was being first used, by breakpointing GC_add_to_heap. Address
808c020 is being mapped at the following stack:

#0  GC_add_to_heap (p=0x808c000, bytes=131072) at
#1  0xf7fcbd68 in GC_expand_hp_inner (n=16) at
#2  0xf7fd8f85 in GC_init_inner () at ../../../src/memory/boehmgc/misc.c:706
#3  0xf7fd2e95 in GC_generic_malloc_inner (lb=351, k=2) at
#4  0xf7fd2f6a in GC_generic_malloc (lb=351, k=2) at
#5  0xf7fd3adf in GC_malloc_uncollectable (lb=351) at
#6  0xf7fd2a3d in malloc (lb=352) at ../../../src/memory/boehmgc/malloc.c:320
#7  0x002d4cef in __fopen_internal () from /lib/libc.so.6
#8  0x002d72cc in fopen64 () from /lib/libc.so.6
#9  0x0069b234 in ?? () from /lib/libselinux.so.1
#10 0x0069d136 in ?? () from /lib/libselinux.so.1
#11 0x00278fc0 in ?? () from /lib/ld-linux.so.2
#12 0xf7bb69e0 in ?? ()
#13 0xffc1d708 in ?? ()
#14 0x0068d2b1 in _init () from /lib/libselinux.so.1

The address is consistent in my program, so I tried setting a debugger
watchpoint on it. This block of memory is not written-to until after the GC
reports it as leaked and calls GC_free on it.

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

- --BDS
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - https://enigmail.mozdev.org


More information about the Gc mailing list