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 <olh@suse.de> 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 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 <pthread.h> #include <sched.h> #include <stdio.h> #include <unistd.h> void* myThread(void* arg) { printf("**** Success, created thread exiting\n"); return (0); } int main(int argc, char** argv) { pthread_attr_t attr; int priority = 0; struct sched_param schedParam; int status; pthread_t threadId; pthread_attr_init(&attr); schedParam.sched_priority = priority; if (pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED) != 0) { printf("pthread_attr_setinheritsched failed\n"); } else if (pthread_attr_setschedpolicy(&attr, SCHED_OTHER) != 0) { printf("pthread_attr_setschedpolicy failed\n"); } else if (pthread_attr_setschedparam(&attr, &schedParam) != 0) { printf("pthread_attr_setschedparam failed\n"); } else { printf("Will create thread with priority %d\n", priority); status = pthread_create(&threadId, &attr, myThread, 0); printf("Thread creation returned %d\n", status); sleep(2); } printf("Main thread exiting\n"); return (0); } $ g++ -g -lpthread -o run pthread2.cpp $ gdb run 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"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) break myThread Breakpoint 1 at 0x100006ac: file pthread2.cpp, line 10. (gdb) run Starting program: /home/sr9690/test/srvcoretest/run [Thread debugging using libthread_db enabled] [New Thread 1074001984 (LWP 12491)] Will create thread with priority 0 [New Thread 1078197024 (LWP 12494)] Thread creation returned 0 [Switching to Thread 1078197024 (LWP 12494)] Breakpoint 1, myThread (arg=0x0) at pthread2.cpp:10 10 printf("**** Success, created thread exiting\n"); (gdb) bt #0 myThread (arg=0x0) at pthread2.cpp:10 #1 0x0ffe3048 in start_thread () from /lib/tls/libpthread.so.0 #2 0x0fda9dd8 in clone () from /lib/tls/libc.so.6 #3 0x0fda9dd8 in clone () from /lib/tls/libc.so.6 Previous frame identical to this frame (corrupt stack?) (gdb) -------------------------------- Thanks for your help Sid
On Wed, Aug 03, Sid wrote:
On 8/2/05, Olaf Hering <olh@suse.de> 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 <olh@suse.de> wrote:
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