|
|
On Wed, Jul 1, 2009 at 7:35 AM, Andrew Haley<aph@xxxxxxxxxx> wrote:
> Dave Korn wrote:
>> NightStrike wrote:
>>
>>> (gdb) run
>>> Starting program:
>>> /home/nightstrike/root-x86_64-pc-linux-64/bin/x86_64-w64-mingw32-g++
>>> -v
>>> *** glibc detected *** malloc(): memory corruption (fast):
>>> 0x0000000000543570 ***
>>>
>>> Program received signal SIGABRT, Aborted.
>>> 0x00002aaaaabf207b in raise () from /lib/libc.so.6
>>> (gdb) bt
>>> #0 0x00002aaaaabf207b in raise () from /lib/libc.so.6
>>> #1 0x00002aaaaabf384e in abort () from /lib/libc.so.6
>>> #2 0x00002aaaaac285f9 in __libc_message () from /lib/libc.so.6
>>> #3 0x00002aaaaac2fbee in _int_malloc () from /lib/libc.so.6
>>> #4 0x00002aaaaac3116d in malloc () from /lib/libc.so.6
>>> #5 0x0000000000419a98 in xmalloc (size=3651) at
>>> ../../gcc/libiberty/xmalloc.c:147
>>
>> Argh. Sorry for leading you slightly astray; the tricky thing about malloc
>> overwrite bugs is that they generally don't hit until a *later* malloc or
>> free
>> tries to (re/de-)allocate the following memory area.
>>
>> You might be able to get at it by breakpointing at the start of the arg
>> handling code in g++spec.c, and setting a watchpoint on one-after-the-end-of
>> the argv array, for example.
>
> Valgrind Memcheck is your friend.
>
> Andrew.
>
I don't know how to use that. Is it available on the compile farm?
|
|