Lassi Tuura <[email protected]> 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 <[email protected]> PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
