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 <[email protected]> wrote: > On Sun, Sep 21, 2014 at 8:34 PM, Jared Cantwell > <[email protected]> wrote: >> I've turned off address space randomization and looked for an IP in >> the vdso range. >> >> jared@jared-vb:~/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 _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
