Re: memory allocation bug in g++-4.1.2 and glibc

[Paul Pluzhnikov]

alikin <shahrokni@gmail.com> writes:

> So does that imply that the heap corruption might be in the first bit
> of code which generates the data?

I can't tell from your description.

>From what I understood:
- you've split your program into two parts, and now neither crashes

- VG doesn't give any errors for the first part, and only "read
  uninitialized" for the second part, which doesn't explain the crash.

- the second part crashes with this stack trace:

> #0  0x402bc847 in raise () from /lib/libc.so.6
> #1  0x402be0b8 in abort () from /lib/libc.so.6
> #2  0x402f2c1b in __libc_message () from /lib/libc.so.6
> #3  0x402fb317 in _int_malloc () from /lib/libc.so.6
> #4  0x402fcb3e in malloc () from /lib/libc.so.6
> #5  0x4022d908 in operator new () from /usr/lib/libstdc++.so.6
> #6  0x4022da3d in operator new[] () from /usr/lib/libstdc++.so.6
>
> Does that mean anything?!

Yes, it means you have corrupted heap (in whichever process is
crashing).

It would be *extremely* strange is VG does not report any heap
corruption errors, but you get the crash above.

What's likely happening is that VG does report a heap corruption
error, but you don't notice it among all the "read uninitialized"
noise. Here is what "heap corruption" looks like in VG output:

$ cat junk.cpp
int main()
{
    char *p = new char[10];
    p[10] = 'a'; // Write beyond allocated
    delete p;    // Delete mismatch, should be "delete [] p;"
}

$ g++ -g junk.cpp && valgrind ./a.out
==16933== Memcheck, a memory error detector.
...
==16933== Invalid write of size 1
==16933==    at 0x4005D6: main (junk.cpp:4)
==16933==  Address 0x4C2703A is 0 bytes after a block of size 10 alloc'd
==16933==    at 0x4A05D29: operator new[](unsigned long) 
(vg_replace_malloc.c:199)
==16933==    by 0x4005C9: main (junk.cpp:3)
==16933== 
==16933== Mismatched free() / delete / delete []
==16933==    at 0x4A051A0: operator delete(void*) (vg_replace_malloc.c:244)
==16933==    by 0x4005E1: main (junk.cpp:5)
==16933==  Address 0x4C27030 is 0 bytes inside a block of size 10 alloc'd
==16933==    at 0x4A05D29: operator new[](unsigned long) 
(vg_replace_malloc.c:199)
==16933==    by 0x4005C9: main (junk.cpp:3)

Look for *these* kinds of errors in VG output.

> Also with the latest version of glibc (2.5-2) I get this error at run
> time:
> *** glibc detected *** ./ibr_render: malloc(): memory corruption:
> 0x0876dd08 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0x402fb317]
> /lib/libc.so.6(malloc+0x7e)[0x402fcb3e]
> /usr/lib/libstdc++.so.6(_Znwj+0x28)[0x4022d908]
> /usr/lib/libstdc++.so.6(_Znaj+0x1d)[0x4022da3d]
> ./ibr_render[0x805f26b]
> ./ibr_render[0x805107f]
> ./ibr_render[0x805171e]
> /lib/libc.so.6(__libc_start_main+0xd8)[0x402a8878]
> ./ibr_render(__gxx_personality_v0+0xa1)[0x804c031]
...
> which doesn't mean anything to me, but I find the 0's in heap line
> suspicious.

The error is telling you exactly the same thing you already know --
ibr_render dies with heap corruption. The 0's in the heap line
are expected.

If VG really doesn't tell you where heap corruption happens (which
implies a bug in VG), you can try to set a watchpoint on the address
glibc reports, and see which code last writest to that location
(before the crash). That code likely writes to dangling memory.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.