[Gc] moving from 6.8->7.0 getting smashed objects

jim marshall jim.marshall at wbemsolutions.com
Thu Jul 19 22:15:12 PDT 2007


Boehm, Hans wrote:
> I think the algorithm for detecting smashed objects has not changed.
> Lots of other things, including object placement, no doubt have.  It's
> quite conceivable that either:
>
> 1) Other changes cause the overwrite to be noticed in 7.0 but not 6.8
> 2) There is another bug in 7.0
>
> I would hope that it wouldn't take that long to debug this from the
> smashed object messages?  It should be fairly easy to determine where
> objects in the vicinity were allocated.  If the problem is repeatable
> enough, a watchpoint on the overwritten location might even work.
>   
I've not made much headway with this, perhaps someone could point me in 
the direction to go.

Basically what I have found is that at some point our program calls 
GC_MALLOC (gc_debug_malloc - as we are using a debug build). This call 
returns successfully (no smashed objects). However the very next 
allocation causes the GC to spit out the smashed object warning. Here is 
a GDB session to give an example:

wsi_malloc (pSize=78) at src/wsimemory.c:47
47          void *mem = GC_MALLOC(pSize);
(gdb) s
GC_debug_malloc (lb=78, s=0x400535c9 "src/wsimemory.c", i=47) at dbg_mlc.c:457
457     {
(gdb) n
458         void * result = GC_malloc(lb + DEBUG_BYTES);
(gdb) 
460         if (result == 0) {
(gdb) 
458         void * result = GC_malloc(lb + DEBUG_BYTES);
(gdb) 
460         if (result == 0) {
(gdb) 
467         if (!GC_debugging_started) {
(gdb) 
471         return (GC_store_debug_info(result, (word)lb, s, (word)i));
(gdb) print result
$1 = (void *) 0x809df70
(gdb) n
472     }
(gdb) 
wsi_malloc (pSize=78) at src/wsimemory.c:50
50          memset(mem, 0, pSize);
(gdb) print mem
$2 = (void *) 0x809df80
(gdb) call GC_debug_malloc(64, "myfile.c", 1)
GC_check_heap_block: found smashed heap objects:
0x80d1008 in object at 0x80d1000(<smashed>, appr. sz = 197)
$3 = (void *) 0x80a9f88
(gdb) 


You can see above that we call GC_debug_malloc, this returns. Now before 
I executed line 50 (the memset call) I had GDB 'call GC_debug_malloc' 
directly and it detects the smashed object.

You can see the smashed object is at 0x80d1000 which is consistent, but 
I can not find a place where this address is returned to my application 
(I set breaks in all the GC allocate functions I could and nothing 
returned seemed to be in that range). As an aside to the previous 
sentence, our application makes a lot of allocation calls, so while I 
set the break points, I didn't enable them for a while. I tried setting 
conditional breaks in GC_debug_malloc (and others) for when 
result==0x80d1000, but they never got hit.

Setting a watch point on those memory locations cause the program to 
crawl (or hang - I couldn't determine). My test machine is a Celeron and 
GDB does not use a hardware watch when I use the watch command on the 
memory address.

Any ideas on what else I can do to help determine if this is in our app 
(which is my suspicion) or an issue with GC 7.0?

Thanks!
-Jim


More information about the Gc mailing list