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

[Henrik Grindal Bakken]

Lassi Tuura <address@hidden> writes:

> Hi,
>
>> 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/
>
> This shows for the last few frames:
>
>   IP 0x4023ec4c, SP 0x40b8cdd0
>    >_Uarm_dwarf_find_proc_info: looking for IP=0x4023ec4b
>    >_Uarm_dwarf_find_debug_frame: Trying to find .debug_frame 
> info->dlpi_name=/lib/libpthread.so.0
>    >_Uarm_dwarf_find_proc_info: IP=0x4023ec4b not found
>    >_Uarm_dwarf_step: returning -10 [= UNW_ENOINFO]
>    >_Uarm_step: dwarf_step() failed (ret=0), trying frame-chain
>
>   IP 0x4023eb64, SP 0x40b8cdd0
>    >_Uarm_dwarf_find_proc_info: looking for IP=0x4023eb63
>    >_Uarm_dwarf_find_debug_frame: Trying to find .debug_frame 
> info->dlpi_name=/lib/libpthread.so.0
>    >_Uarm_dwarf_find_proc_info: IP=0x4023eb63 not found
>    >_Uarm_dwarf_step: returning -10 [= UNW_ENOINFO]
>    >_Uarm_step: dwarf_step() failed (ret=0), trying frame-chain
>
>    (boom? or it just finished here in those access_mem() calls? It
>    seems next IP would be 0xeaff320c?)

Yeah, it was boom.  The "Segmentation Fault" line wasn't redirected to
the file.

> If it crashes there it looks like you have (thread wrapper/start?)
> functions in libpthread.so which are missing unwind info, and the
> ARM frame-chain fallback stack walk code isn't understanding what it
> finds there, and dies.
>
> I think the corresponding bits of your earlier GDB trace must be:
>
>    #21 0x4023dc4c in ?? () from /lib/libpthread.so.0
>    #22 0x4023dc4c in ?? () from /lib/libpthread.so.0
>
> It's not the same addresses though. Does GDB fail to walk the stack
> here too, producing infinite supply of 0x4023dc4c?

Actually, gdb now managed to complete the trace.  I also think that
the reason it didn't work with our abstraction layer is that it adds
stack guards (with mprotect()) before and after the stack.  I suspect
that's what's killing the unwind early.

I'm closing in on this problem now, I think.  In my latest iteration,
without using our abstraction layer, it actually goes all the way
through (with an explicit bailout if ip == NULL).

> PS. Your local_obtain_backtrace() doesn't handle destsize == 0
> properly, maybe change the do/while loop to while one, or add an
> explicit check for zero.

Added an explicit check in the beginning of the function.  Thanks.

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