[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mu
From: |
Jared Cantwell |
Subject: |
Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock |
Date: |
Sun, 21 Sep 2014 09:04:23 -0600 |
I've turned off address space randomization and looked for an IP in
the vdso range.
address@hidden:~/unwindrepro$ ldd a.out
linux-gate.so.1 => (0xb7fff000) <----- vdso range
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7fcf000)
.......
Running with UNW_DEBUG_LEVEL=16 shows the following for the final
failing unw_step call. It doesn't look like the IP is in the vdso
range, but I could be misreading. To me though, it looks like the IP
falls into libpthread, which the debug output appears to correctly
show.
>_ULx86_step: (cursor=0xb7c96930, ip=0xb7fb5ead)
>get_rs_cache: acquiring lock
>_ULx86_dwarf_find_proc_info: looking for IP=0xb7fb5eac
>_ULx86_dwarf_callback: checking , base=0x0)
>_ULx86_dwarf_callback: checking , base=0xb7fdf000)
>_ULx86_dwarf_callback: checking
/lib/i386-linux-gnu/libpthread.so.0, base=0xb7fad000)
>_ULx86_dwarf_callback: found table
`/lib/i386-linux-gnu/libpthread.so.0': segbase=0xb7fbea74, len=684,
gp=0xb7fc4ff4, table_data=0xb7fbea80
Am I reading this properly, or is this actually the vdso problem?
~Jared
On Sat, Sep 20, 2014 at 9:54 AM, Arun Sharma <address@hidden> wrote:
> On Sat, Sep 20, 2014 at 8:55 PM, Paul Pluzhnikov <address@hidden> wrote:
>> On Sat, Sep 20, 2014 at 7:21 AM, Arun Sharma <address@hidden> wrote:
>>
>>> If dl_iterate_phdr() returned vDSO, I think libunwind will just work.
>>> However, a recent commit linked to:
>>>
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=16046
>>>
>>> removed the vdso from user visible API.
>>
>> I do not believe above statement is correct: vdso is most definitely
>> still returned by dl_iterate_phdr (at least for dynamically-linked
>> binaries).
>>
>
> You're right. I didn't carefully look at the output of the test
> program in the bug.
>
> $ ./t1
> addr=(nil) name= phdr=0x400040 phnum=9
> addr=0x7fff49afe000 name= phdr=0x7fff491fe040 phnum=4
> <------------------- vdso (which I missed)
> addr=0x7f6628e90000 name=/lib/x86_64-linux-gnu/libc.so.6
> phdr=0x7f6628e90040 phnum=10
> addr=0x7f6629258000 name=/lib64/ld-linux-x86-64.so.2 phdr=0x7f6629258040
> phnum=7
>
> $ ldd t1
> linux-vdso.so.1 => (0x00007fffe79fe000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f80d480b000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f80d4bea000)
>
> Is there a way to recognize the vdso from the output of
> dl_iterate_phdr (other than name=null?). I'd like UNW_DEBUG_LEVEL to
> print something more informative when it finds the vdso.
>
> -Arun
- [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Jared Cantwell, 2014/09/15
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Jared Cantwell, 2014/09/16
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Masatake YAMATO, 2014/09/17
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Paul Pluzhnikov, 2014/09/20
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Arun Sharma, 2014/09/20
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock,
Jared Cantwell <=
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Arun Sharma, 2014/09/21
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Jared Cantwell, 2014/09/26
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Arun Sharma, 2014/09/27
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Jared Cantwell, 2014/09/27
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Arun Sharma, 2014/09/29
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Arun Sharma, 2014/09/29
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Vladimir Nikulichev, 2014/09/29
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Tim Deegan, 2014/09/29
- Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock, Jared Cantwell, 2014/09/29