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. _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
