[Gc] Smashed heap objects

BGB cr88192 at gmail.com
Sun Jan 2 19:46:20 PST 2011

On 1/2/2011 4:16 PM, Maksim Sipos wrote:
> Hello All,
> When running my program I get the following errors from the Boehm GC
> (with GC_DEBUG defined):
> GC_check_heap_block: found smashed heap objects:
> 0x8ef1008 in or near object at 0x8ef1010(<smashed>, appr. sz = 29)
> 0x8ef1188 in or near object at 0x8ef1190(<smashed>, appr. sz = 29)
> ...
> The above continues many times.
> Oddly, I can't find anything wrong with the program, it does what it is
> supposed to, and does not crash. It passes all the unit tests also.
> I can compile my program disabling the GC. Then I can run valgrind with
> it, but oddly enough, valgrind doesn't find any problems. (Of course,
> the program balloons up to 300mb.)
> Does anyone have any ideas how to effectively debug this?  How is it
> possible that valgrind does not show any errors but GC does?
> Or, can anyone please explain what precisely the above messages mean?
> The system is Arch Linux x86, gc 7.1, gcc 4.5.2.  The problem happens
> when I disable threads as well, so all I really do is call GC_INIT()
> first.  I use GC_MALLOC(), GC_REALLOC(), GC_FREE(), and a few times

so, you are certain you are not overflowing any arrays or buffers, all 
objects are allocated with the correct sizes, ... ?

dunno about Boehm, but a custom MM I had used before had helped debug 
this sort of thing with a trick:
it would detect damaged memory, and locate the last object with 
everything still intact;
all allocation requests would track the originating source filename and 
line (the allocation request was wrapped in a macro);
the result was that it would return a message with the source file and 
line where the (most-likely) offending object was allocated, giving a 
starting point for tracking down the error...

sadly, my main GC doesn't do this, since I don't have enough bits left 
over in the header in which to put a key into a source-file and 
line-number table (would likely need at least 12 or 14 or so bits for 
this, and at the moment it isn't likely worthwhile expanding object 
headers to 16 bytes or so to store this info, vs the current 8 byte 

granted, depending on what exactly is being done, valgrind may not 
necessarily see memory damage. or there may be "the debugger effect" 
which is usually where a debugger may subtly change the behavior of a 
misbehaving piece of code in such a way as to make a problem not 
reproducible in a debugger (like, a program which always works correctly 
in the debugger, but always fails "in the wild"). (sometimes the reverse 
is true, but this is generally easier to fix...).

the above effect (debugger effect) seems most common IME in apps which 
accidentally use uninitialized memory, I suspect, because non-debugged 
apps more often get memory containing garbage, but apps being debugged 
get zeroed memory, or something like this...

or such...

More information about the Gc mailing list