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

[Lassi Tuura]

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

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?

Regards,
Lassi

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.