[Bug malloc/32996] malloc regression on i686

[wdijkstr at arm dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32996

--- Comment #9 from Wilco <wdijkstr at arm dot com> ---
(In reply to dj@redhat.com from comment #8)
> I've been debugging this for a couple of days, my findings so far... 
> 
> something is corrupting Qt's memory (i.e. the heap), I think, although I
> don't know who yet.  It ends up calling free() with a pointer that was never
> returned by any malloc API.  That pointer points to the word before the next
> chunk, and that word is all zeros, but probably because it's the last word
> of an in-use chunk (the next word is 0x61, which has the PREV_CHUNK_INUSE
> bit set, and corresponds to chunks passed by the malloc API)

So it may have been a legal malloc block but the pointer was decremented
somehow? If you know the address that contains the bad pointer 0x56890a48 (I
guess it must come from the class that calls free), setting a watchpoint might
be able to find which code caused the corruption.

> Unfortunately, I've found that the use of any interposer makes the problem
> "go away" - so no tracer, or valgrind, etc.  That means I've annotated my
> copy of malloc.c with a ton of write() calls to debug this ;-)

This is a scenario where it would be useful to have ifuncs for malloc that
allow one to switch to a debug version in a way that does not affect any malloc
addresses - then you could run whole heap consistency checks on every
malloc/free.

-- 
You are receiving this mail because:
You are on the CC list for the bug.