Re: [Libunwind-devel] Re: Backtrace from signal handler on arm from threads

[Lassi Tuura]

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