[Top][All Lists]
[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 12:30:28 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
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
- [Libunwind-devel] Re: Backtrace from signal handler on arm from threads, (continued)
- Re: [Libunwind-devel] Re: Backtrace from signal handler on arm from threads, Lassi Tuura, 2011/02/03
- [Libunwind-devel] Re: Backtrace from signal handler on arm from threads, Henrik Grindal Bakken, 2011/02/03
- Re: [Libunwind-devel] Re: Backtrace from signal handler on arm from threads, Lassi Tuura, 2011/02/03
- Re: [Libunwind-devel] Re: Backtrace from signal handler on arm from threads, Paul Pluzhnikov, 2011/02/03
- [Libunwind-devel] Re: Backtrace from signal handler on arm from threads, Henrik Grindal Bakken, 2011/02/08
- Re: [Libunwind-devel] Re: Backtrace from signal handler on arm from threads, Lassi Tuura, 2011/02/03
- [Libunwind-devel] Re: Backtrace from signal handler on arm from threads,
Henrik Grindal Bakken <=