Re: [Libunwind-devel] UNW_EINVAL stepping past _L_lock_686 in pthread_mutex_lock

[Jared Cantwell]

I have reproduced this on ubuntu 14.04 and 13.10.  Configuration
information below.  I've also tested on 3.14 kernel and eglibc 2.18
without any luck.  Arun, if my test passes for you on 13.10 can you
provide information on your setup so I can compare?

Does the fact that gdb can unwind this stack mean anything?  Like that
the unwind information is in libpthread in some form that libunwind
doesn't quite understand?

ubuntu 14.04
3.13.0-29-generic
GNU C Library (Ubuntu EGLIBC 2.19-0ubuntu6.3) stable release version
2.19, by Roland McGrath et al.
g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2

ubuntu 13.10
3.11.0-23-generic
GNU C Library (Ubuntu EGLIBC 2.17-93ubuntu4) stable release version
2.17, by Roland McGrath et al.
g++ (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1

~Jared


On Sun, Sep 21, 2014 at 9:21 AM, Arun Sharma <address@hidden> wrote:
> On Sun, Sep 21, 2014 at 8:34 PM, Jared Cantwell
> <address@hidden> wrote:
>> 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.
>>
> [..]
>> Am I reading this properly, or is this actually the vdso problem?
>>
>
> Yeah - looks like a libpthread problem. readelf -wf should help you
> get to the code in libpthread which is missing the unwind info. Please
> check if it's fixed in glibc HEAD.
>
>  -Arun