Re: [maemo-developers] Problem with GDB and threads...
Hi, This finally did the trick. I configured and compiled glibc using ./configure [...] CFLAGS=-g -O2 -fno-omit-frame-pointer Now the backtrace doesn't repeat forever, although I still get Previous frame identical to this frame (corrupt stack?). To debug functions which do not return (have attribute((noreturn))), you need to compile those functions with -fno-omit-frame-pointer (or remove the noreturn attribute). Both omitting a frame-pointer and noreturn attribute are just optimizations. To debug a static function (by debugging I mean having a backtrace going through that function), you need debug symbols for the library in which the function resides. libc6 debug package is quite large, but you can remove the .so files directly in /usr/lib/debug/ as Gdb works just fine also with the (smaller/newer) debug symbol files in the subdirectories of /usr/lib/debug/. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with GDB and threads...
On Tuesday 18 July 2006 19:35, Christian Henz wrote:
The compilation of glibc did not explicitly use -fomit-frame-pointer, but
the GCC manual states that -O implies it on architectures where it
doesn't break debugging. Unfortunately it doesn't mention which
architectures those are. I'm currently recompiling glibc with explicitly
setting
-fno-omit-frame-pointer.
This finally did the trick. I configured and compiled glibc using
./configure [...] CFLAGS=-g -O2 -fno-omit-frame-pointer
Now the backtrace doesn't repeat forever, although I still get Previous frame
identical to this frame (corrupt stack?).
# gdb ./testc-armel
GNU gdb 6.4
Copyright 2005 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 arm-linux-gnueabi...Using host libthread_db
library /usr/lib/debug/libthread_db.so.1.
(gdb) break test.c:26
Breakpoint 1 at 0x84f4: file test.c, line 26.
(gdb) run
Starting program: /mnt/nessie/nokia770/testc-armel
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1127)]
BFD: /usr/lib/debug/lib/ld-2.3.6.so: warning: sh_link not set for section
`.ARM.exidx'
[New Thread 32769 (LWP 1130)]
[New Thread 16386 (LWP 1131)]
[Switching to Thread 16384 (LWP 1127)]
Breakpoint 1, main (argc=1, argv=0xbe8e2744) at test.c:26
26 test.c: No such file or directory.
in test.c
(gdb) thread apply all bt
Thread 3 (Thread 16386 (LWP 1131)):
#0 0x40115a84 in sched_yield () at regex_internal.c:71
#1 0x40029af8 in __pthread_acquire (spinlock=0x40037d1c) at spinlock.c:711
#2 0x40024c90 in pthread_start_thread_event (arg=0xbe1ffbe0) at manager.c:329
#3 0x4012ae10 in clone () from /usr/lib/debug/libc.so.6
#4 0x4012ae10 in clone () from /usr/lib/debug/libc.so.6
Previous frame identical to this frame (corrupt stack?)
Thread 2 (Thread 32769 (LWP 1130)):
#0 0x40121f08 in *__GI___poll (fds=0x13000, nfds=1, timeout=2000)
at ../sysdeps/unix/sysv/linux/poll.c:86
#1 0x4002520c in __pthread_manager (arg=0xfffc) at manager.c:152
#2 0x40025a88 in __pthread_manager_event (arg=0x46b) at manager.c:249
#3 0x4012ae10 in clone () from /usr/lib/debug/libc.so.6
#4 0x4012ae10 in clone () from /usr/lib/debug/libc.so.6
Previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 16384 (LWP 1127)):
#0 main (argc=1, argv=0xbe8e2744) at test.c:26
(gdb)
cheers,
Christian Henz
#include unistd.h
#include assert.h
#include pthread.h
void* routine( void* arg ) {
int i = 0;
while( i 15 ) {
sleep( 1 );
i++;
}
return 0;
}
int main( int argc, char** argv ) {
pthread_t handle;
void* retval;
int err = pthread_create( handle, 0, routine, 0 );
assert( err == 0 );
err = pthread_join( handle, retval );
assert( err == 0 );
return 0;
}
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with GDB and threads...
On Friday 14 July 2006 08:37, Eero Tamminen wrote: Hi, On the Nokia 770, the backtrace goes on forever and i have to kill gdb Have you compiled your binary: - without optimization (or used -no-omit-frame-pointer) - with -g - not stripped it ? If not, if you do that and try again, does the debugging work better? I simply compiled with -g before, adding the -no-omit-frame-pointer directive did not help. If it still doesn't work, does it work if you install 'libc6-dbg' package and run your program, or GDB starting your program, with: LD_LIBRARY_PATH=/usr/lib/debug:$LD_LIBRARY_PATH gdb /path/app ? I can't seem to find that package in the mistral repositories. cheers, Christian Henz ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with GDB and threads...
Hi, I simply compiled with -g before, adding the -no-omit-frame-pointer directive did not help. Actually I think the library where the function giving infinite backtrace is should be compiled with -g (or debug package for it should be installed). If that doesn't help then you need to compile that library / binary with -fno-omit-frame-pointer. At least one reason for the infinite backtraces has been __attribute__ ((__noreturn__)) specified to functions. That is given to functions that do not return and for them -fno-omit-frame-pointer is needed to get working backtrace, for them -g is not enough. Normally those are exit functions, but maybe thread creation function doesn't return either? (I've seen some thread usage example code where __noreturn__ attribute is used for them) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] Problem with GDB and threads...
Hi, On the Nokia 770, the backtrace goes on forever and i have to kill gdb Have you compiled your binary: - without optimization (or used -fno-omit-frame-pointer) - with -g - not stripped it ? If not, if you do that and try again, does the debugging work better? If it still doesn't work, does it work if you install 'libc6-dbg' package and run your program, or GDB starting your program, with: LD_LIBRARY_PATH=/usr/lib/debug:$LD_LIBRARY_PATH gdb /path/app ? Has anyone else experienced this? Also, why is there an extra thread? Thread manager polling the other threads? (Using threads on ARM should be avoided unless absolutely necessary) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
