[maemo-developers] [maemo-developers] Problem with GDB and threads...

[From: Christian Henz]

On Tuesday 18 July 2006 15:23, Eero Tamminen wrote:
> 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.
>

Since I could not find a binary libc6-dbg package, I compiled it myself from 
the package source. But it still does not work:

# 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) r
Starting program: /mnt/nessie/nokia770/testc-armel
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 1146)]
BFD: /usr/lib/debug/lib/ld-2.3.6.so: warning: sh_link not set for section 
`.ARM.exidx'
[New Thread 32769 (LWP 1149)]
[New Thread 16386 (LWP 1150)]

Program received signal SIGINT, Interrupt.
[Switching to Thread 16386 (LWP 1150)]
0x400f937c in nanosleep () at stdlib.h:338
338     stdlib.h: No such file or directory.
        in stdlib.h
(gdb) thread apply all bt

Thread 3 (Thread 16386 (LWP 1150)):
#0  0x400f937c in nanosleep () at stdlib.h:338
#1  0x400f9164 in __sleep (seconds=0) 
at ../sysdeps/unix/sysv/linux/sleep.c:138
#2  0x00008488 in routine (arg=0x0) at test.c:11
#3  0x40024a20 in pthread_start_thread (arg=0xfffffdfc) at manager.c:310
#4  0x40024a20 in pthread_start_thread (arg=0xfffffdfc) at manager.c:310
#5  0x40024a20 in pthread_start_thread (arg=0xfffffdfc) at manager.c:310
#6  0x40024a20 in pthread_start_thread (arg=0xfffffdfc) at manager.c:310
#7  0x40024a20 in pthread_start_thread (arg=0xfffffdfc) at manager.c:310
#8  0x40024a20 in pthread_start_thread (arg=0xfffffdfc) at manager.c:310
#9  0x40024a20 in pthread_start_thread (arg=0xfffffdfc) at manager.c:310
#10 0x40024a20 in pthread_start_thread (arg=0xfffffdfc) at manager.c:310
#11 0x40024a20 in pthread_start_thread (arg=0xfffffdfc) at manager.c:310
[...]



> 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)
>

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".

Thanks so far :-)
Christian