From: "Zarges, Olav" <Olav.Zarges@imc-berlin.de>
To: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: gdb-6.5 produces infinite backtrace on ARM
Date: Tue, 15 Aug 2006 08:15:00 -0000 [thread overview]
Message-ID: <44E181DE.7040905@imc-berlin.de> (raw)
Hi all,
Environment:
cross gdb-6.5 running on cygwin, gcc-3.4.4-glibc-2.3.5 for ARM,
Eclipse and CDT as a front end.
When debugging a multithreaded application on ARM I get inifinite
backtrace showing pthread_start_thread(). When using Eclipse as a
GDB front-end I had to use "set backtrace limit" to limit the
backtrace to a sensible value, otherwise the Eclipse debugger hangs
forever when the program hits a breakpoint.
While the thread with the breakpoint has inifinite backtrace the
other thread shows "Previous frame identical to this frame (corrupt
stack?)" (Eclipse doesn't show a call stack at all; command line
GDB shows the frames up to this message).
Reading the newsgroups I found that many people had similar problems
(is there a solution available?).
I found the hint to use DWARF CFI to set the function called by
pthread_create() or maybe pthread_create() itself to non-unwindable.
Can anybody tell me how to do it for this sample program?
Regards Olav
>>>>
compiler-run:
arm-softfloat-linux-gnu-g++ -O0 -g3 -Wall -c -fmessage-length=0
-MMD -MP -MF"threads.d" -MT"threads.d" -o"threads.o" "../threads.cpp"
linker-run:
arm-softfloat-linux-gnu-g++ -o"threads" ./threads.o -lpthread
>>>>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>
void* thread_function1(void*) {
int a = 0;
while (1) {
for (int i=0 ; i<100; i++) {
a += i;
}
printf("Thread 1: %d\n", a);
sleep(3);
}
return NULL;
}
void* thread_function2(void*) {
int a = 0;
while (1) {
for (int i=0 ; i<100; i++) {
a += i;
}
printf("Thread 2: %d\n", a);
sleep(2);
}
return NULL;
}
int main(int argc, char **argv) {
pthread_t thread1, thread2;
// create all the threads
pthread_create( &thread1, NULL, thread_function1, NULL );
pthread_create( &thread2, NULL, thread_function2, NULL );
sleep(1);
// wait for threads to end (.. I know this can't happen)
pthread_join( thread1, NULL );
pthread_join( thread2, NULL );
return 0;
}
--
Olav A. Zarges
imc MeÃsysteme GmbH
Voltastr. 5
13355 Berlin
Deutschland
Tel: 030 / 467090-68
Fax: 030 / 4631576
next reply other threads:[~2006-08-15 8:15 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-15 8:15 Zarges, Olav [this message]
2006-08-15 12:41 ` Daniel Jacobowitz
2006-08-15 13:54 ` Zarges, Olav
2006-08-19 5:24 ` Daniel Jacobowitz
2006-08-21 11:35 ` Zarges, Olav
2006-08-21 12:42 ` Daniel Jacobowitz
2006-08-21 14:37 ` Zarges, Olav
2006-08-21 14:54 ` Daniel Jacobowitz
2006-09-06 13:32 ` Zarges, Olav
2006-09-06 14:44 ` Daniel Jacobowitz
2006-09-06 15:03 ` Zarges, Olav
2006-09-06 15:19 ` Daniel Jacobowitz
2006-09-06 15:38 ` Zarges, Olav
2006-09-06 15:52 ` Daniel Jacobowitz
2006-09-07 16:15 ` Zarges, Olav
2006-09-07 17:38 ` Daniel Jacobowitz
2006-09-10 14:49 ` Daniel Jacobowitz
2006-09-19 1:40 ` Michael Snyder
2006-09-19 3:17 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44E181DE.7040905@imc-berlin.de \
--to=olav.zarges@imc-berlin.de \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox