alikin <[EMAIL PROTECTED]> 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.
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
