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