libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Henrik Grindal Bakken
Subject: [Libunwind-devel] Re: Backtrace from signal handler on arm from threads
Date: Thu, 03 Feb 2011 11:05:13 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Lassi Tuura <address@hidden> writes:

> Hi,
>
>> Here we go:
>> 
>> The readelf output is at http://folk.uio.no/hgb/readelf.output.gz
>> 
>> GDB session: http://fpaste.org/jPwF/
>> 
>> It appears to SEGFAULT upon calling sigprocmask().
>> 
>> "UNW_DEBUG_LEVEL=1011 /tmp/backtrace" actually prints nothing.  It
>> appears to segfault before libunwind manages to output anything at
>> all.
>
> This doesn't sound right. Your backtrace says it's inside unw_step(),
> which must have tried to output something before ending up in a call
> to sigprocmask(). The first statement in arm unw_step() is line:
>
>   Debug (1, "(cursor=%p)\n", c);

Hmm.  I changed stuff a bit, using pthread directly instead of our
(fairly small) abstraction layer around it, and now I get some output
with the debug code.  This helps, and indicates that there's something
troublesome in our abstraction layer.  It's not completely working
yet, though.

Output here:
http://fpaste.org/4jfm/

The code I run is here, btw:
http://fpaste.org/iBAT/
http://fpaste.org/NPpY/
http://fpaste.org/4MwJ/

The 'USE_TTOS' define is /not/ defined.  I ran with --internal, so the
signal handler in the code pasted above is the one which is run.

With USE_TTOS defined, the results are worse.

-- 
Henrik Grindal Bakken <address@hidden>
PGP ID: 8D436E52
Fingerprint: 131D 9590 F0CF 47EF 7963  02AF 9236 D25A 8D43 6E52




reply via email to

[Prev in Thread] Current Thread [Next in Thread]