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

[Paul Pluzhnikov]

alikin <shahrokni@gmail.com> writes:

> My C++ code behaves strangely and breaks at some unexpected point with
> an error message from libc about corrupted memory. Valgrind shows that
> there is no memory leak in my program

Memory leaks do not cause heap corruption, heap corruption does!
Does VG show *any* errors?

> and it does work all fine for some inputs and breaks for some others.

That's very typical for heap corruption bugs.

> my system is debian testing and "g++ -v" gives:
> gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

Version of gcc is probably completely irrelevant.
What is the version of glibc?

> Here is the output of gdb:
> (gdb) bt
> #0  0x402b0947 in raise () from /lib/tls/libc.so.6
> #1  0x402b20c9 in abort () from /lib/tls/libc.so.6
> #2  0x402e5fda in __fsetlocking () from /lib/tls/libc.so.6
> #3  0x402ee3f3 in free () from /lib/tls/libc.so.6
> #4  0x402efc4f in malloc () from /lib/tls/libc.so.6
> #5  0x40222908 in operator new () from /usr/lib/libstdc++.so.6
> #6  0x40222a3d in operator new[] () from /usr/lib/libstdc++.so.6

This stack trace is likely bogus -- malloc() never calls free(),
and __fsetlocking() doesn't call abort() [at least not in glibc-2.5
that I have].

> I did a bit of search and apparently this problem is common in g++4.*
> but g++-3.4 works fine.

The references I find say "crashes under gcc-4 with stack checking enabled".
That's not a problem in gcc-4, it's a problem with user code having
stack overflows.

> Any help on how to get g++-4.1.2 work properly is greatly appreciated.

Look for a bug in your code?
Get glibc that is compiled without -fomit-fp ?

[It appears that your glibc is compiled with -fomit-fp, and if
that's the case, it is completely unsuitable for development].

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