Hi, > Here we go: > > The readelf output is at http://folk.uio.no/hgb/readelf.output.gz > > GDB session: http://fpaste.org/jPwF/ > > It appears to SEGFAULT upon calling sigprocmask(). > > "UNW_DEBUG_LEVEL=1011 /tmp/backtrace" actually prints nothing. It > appears to segfault before libunwind manages to output anything at > all.
This doesn't sound right. Your backtrace says it's inside unw_step(), which must have tried to output something before ending up in a call to sigprocmask(). The first statement in arm unw_step() is line: Debug (1, "(cursor=%p)\n", c); If that isn't producing output, maybe there's something wonky in your libc installation with threads? Can you run normal threaded programs which use vfprintf? Also GDB doesn't appear to be finding debug info for your libunwind. I don't know if that's related or not. At any rate, disassembly for sigprocmask() around address #0 0x4028392c in sigprocmask () from /lib/libc.so.6 should indicate what it's doing, presumably null pointer access since your output said "Illegal memory access at: 0x8". On x86_64 there aren't a lot of memory accesses in that function. There are two -- one PC-relative load, and another to access TLS I think for errno (mov %edx,%fs:(%rax)). If it crashes in attempt to store TLS-relative errno on ARM, that would indicate there's something wrong with your thread setup, and might also explain why you also lose the debug output from libunwind. > If I run my program without creating threads, I get lots of > output. libunwind was built with --enable-debug and > --enable-debug-frame. You could always try building with --disable-block-signals, but that probably just masks the real problem. Did you build libunwind with libatomic_ops? I don't know if it's needed or useful on ARM. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
