Re: [Libunwind-devel] Re: Backtrace from signal handler on arm from threads

[Paul Pluzhnikov]

This is getting into general GDB support, address@hidden bcc'd

On Wed, Feb 2, 2011 at 1:19 AM, Henrik Grindal Bakken <address@hidden> wrote:
> Paul Pluzhnikov <address@hidden>
> writes:
>
>>> Does anyone have any ideas?
>>
>> Run your program under gdb. When GDB stops with the intentional
>> SIGSEGV or SIGABRT, do "sig SIGSEGV" or "sig SIGABRT", which should
>> continue the program into the sigal handler, into obtain_backtrace
>> and into libunwind, and then GDB should stop with another crash. At
>> that point you'll know where this is crashing, and perhaps why. Use
>> the usual debugging techniques if the reason for the crash is not
>> obvious.
>
> Thanks for the tip.  Doing this, the program immediately
> SIGSEGV/SIGABRTs in __errno_location.
>
> (gdb) run
> Starting program: /tmp/backtrace
> warning: Unable to find libthread_db matching inferior's thread
> library, thread debugging will not be available.
> warning: the debug information found in "/lib/libc-2.12.1.so.debug"
> does not match "/lib/libc.so.6" (CRC mismatch).
>
> warning: Unable to find libthread_db matching inferior's thread
> library, thread debugging will not be available.
>
>         I'm a bit confused about those messages.  I'm sure it's a bad
>         thing, but I don't really understand why it's there.  The
>         .so.debug file is made with the relevant objcopy utility
>         using --only-keep-debug from the libc-2.12.1.so file, which
>         is then stripped (--strip-unneeded), and with objcopy
>         --add-gnu-debuglink.
>
>         libthread_db is on target, so I don't really understand why
>         gdb doesn't like it.
>
> (gdb) sig SIGABRT

Is this your entire GDB session, or did you edit out some parts of it?
It is not clear why GDB stopped here. The warning above should not
have caused a stop.

The warning itself means that GDB was unable to dlopen() a
libthread_db that matches libpthread in the inferior (being debugged)
process.

Are you doing native debugging (running GDB on the same machine as the
inferior), or are you in some kind of cross-compilation /
cross-debugging environment?

It looks like you are doing the former, in which case your 'make
install' in glibc appears incomplete -- it should install libthread_db
that matches libpthread.

Of course it could also be a GDB bug. You can see what versions of
libthread_db GDB is trying to use by doing 'set debug libthread-db 1'
(current GDB trunk) or 'set verbose on' (GDB 7.x).

> Continuing with signal SIGABRT.

If at this point the inferior was not already stopped with SIGABRT due
to previous signal (and you edited that part of GDB interaction), then
this may be the wrong place to send SIGABRT.

> Received signal SIGABRT (6) in thread 0x00031460, TID 1933
> Registers:
> R0:     00000007 R1:   00000000 R2:    00000001 R3:   00000008
> R4:     0000078d R5:   00000001 R6:    00031674 R7:   00000000
> R8:     00000000 R9:   bef26a98 R10:   00000001 FP:   00030bec
> PC:     0000b540 IP:   00030638 SP:    00030bd0 LR:   402467e4
> ERR:    00000817 CPSR: 20000010 FAULT: 00000008 TRAP: 0000000e
> OLDMSK: 00000000

Is above output from your program?

> Program received signal SIGSEGV, Segmentation fault.
> 0x4026da98 in __errno_location () from /lib/libc.so.6
>
> (gdb) bt
> #0  0x4026da98 in __errno_location () from /lib/libc.so.6
> #1  0x40294d0c in vfprintf () from /lib/libc.so.6
> #2  0x40299284 in ?? () from /lib/libc.so.6

Sounds like the unwind descriptor for vfprintf() is bad in your
compilation of libc.so.6 (use 'readelf -wf /lib/libc.so.6' to examine
it).

Since vfprintf() is defined in stdio-common/vfprintf.c, bad unwind
info for vfprintf() implies a bug in the compiler (I think).

Please also note that calling any stdio routines from a signal handler
is unsafe.

Cheers,
-- 
Paul Pluzhnikov