[Xenomai] Xenomai and libunwind on ARM Cortex A9

[Philippe Gerum]

On 10/03/2017 01:49 PM, Andreas Glatz wrote:
> Hi
> 
> I implemented the debug signal handle SIGXCPU as described in the
> Xenomai documentation. The glibc function backtrace() returns
> backtraces, but they often are very short (they typically end at the
> signal (restore) handler, and don't show the function which caused the
> SIGXCPU in the first place).

Mm, ok. I did not observe this issue so far. This said, I'm not
routinely using the feature.

> 
> I found libunwind, which is preloaded before starting our application
> and replaces the glibc backtrace handler with unw_backtrace(). This
> works fine most of the time.
> 
> Recently, I discovered that the application crashes with SIGSEGV
> during startup when quite a few SIGXCPUs occur in short succession
> according to the gdb trace. Everything seems to work fine when
> switching back to the glibc backtrace() function though. Now I'm
> wordering if unw_backtrace() is actually not (Xenomai) thread-save.
> Has anyone seen this before [or any other clues]?
> 

No alternate signal stack is used for SIGXCPU by libcobalt, the handler
always runs over the preempted thread's stack. The usual suspect would
be a stack overflow experienced by the receiving thread. Does libunwind
consume significantly more stackspace than glibc's backtrace()? Any
change after increasing the stack space for application threads?

-- 
Philippe.