[Gc] Smashed heap objects
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
> GC_MALLOC_ATOMIC() and GC_STRDUP().
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...
More information about the Gc