PATCH RFA: Add -static-libstdc++ option to g++

[NightStrike]

On Wed, Jul 1, 2009 at 7:24 AM, Dave
Korn<dave.korn.cygwin@googlemail.com> 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.
>
>    cheers,
>      DaveK
>

Backtraces are easy, but what you are describing is more complicated,
and I don't know what I'd be looking for.  Ian's patch (changing 1 to
a 2) works, however, if that helps anyone in solving this.