GDB thinks stack is corrupt.
I'm debugging some code that is multithreaded and involves several dynamically loaded libraries. Unfortunately, GDB always says that the stack is corrupt and can never seem to give me a meaningful stack dump. Are there any known issues with GDB on PPC? Sid ------- Sample ------- Program received signal SIGABRT, Aborted. [Switching to Thread 1074038976 (LWP 17864)] 0x0f5e478c in raise () from /lib/tls/libc.so.6 (gdb) bt #0 0x0f5e478c in raise () from /lib/tls/libc.so.6 #1 0x0f5e609c in abort () from /lib/tls/libc.so.6 #2 0x0f79eda8 in __cxxabiv1::__terminate () from /usr/lib/libstdc++.so.5 #3 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #4 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #5 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #6 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #7 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #8 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #9 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #10 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #11 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #12 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #13 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #14 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #15 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #16 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #17 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 #18 0x0f79ede4 in std::terminate () from /usr/lib/libstdc++.so.5 Previous frame inner to this frame (corrupt stack?) (gdb)
On Mon, Jul 25, Sid wrote:
I'm debugging some code that is multithreaded and involves several dynamically loaded libraries. Unfortunately, GDB always says that the stack is corrupt and can never seem to give me a meaningful stack dump. Are there any known issues with GDB on PPC?
What version of gdb is this?
What version of gdb is this?
$ gdb GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ppc-suse-linux". $ SPident CONCLUSION: System is up-to-date! found SLES-9-ppc-SP2 + "online updates"
On 8/2/05, Olaf Hering
Do you have a simple testcase to demonstrate the problem?
The sample from this bug report works quite well. This is another bug
that I ran into, but it demonstrates gdb's confusion quite well.
http://sources.redhat.com/bugzilla/show_bug.cgi?id=801
I am porting over a significant codebase from AIX and not having
backtrace is a major pain. I am also using XLC, but the problem seems
to not constricted to XLC, since i compiled this with g++.
Here's a capture from a session which includes a listing of the program.
------------------------------
$ cat pthread2.cpp
#include
On Wed, Aug 03, Sid wrote:
On 8/2/05, Olaf Hering
wrote: Do you have a simple testcase to demonstrate the problem?
The sample from this bug report works quite well. This is another bug that I ran into, but it demonstrates gdb's confusion quite well. http://sources.redhat.com/bugzilla/show_bug.cgi?id=801
This fix doesnt help (assuming its already in glibc mainline). sles10 codebase behaves the same, I suggest you open a new gdb bug and assign it to the upstream maintainers.
On 8/4/05, Olaf Hering
This fix doesnt help (assuming its already in glibc mainline). sles10 codebase behaves the same, I suggest you open a new gdb bug and assign it to the upstream maintainers.
Looks like there's a relevant bug report in there already https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129331 The problem with that is that it refers to 2 other bugs at the very bottom (#140532 and #140534), and I dont have sufficient priveleges to see the details of those. Thanks anyways Olaf. Appreciate the help. Sid
participants (2)
-
Olaf Hering
-
Sid