[Xenomai] Xenomai and libunwind on ARM Cortex A9
rpm at xenomai.org
Wed Oct 4 10:54:34 CEST 2017
On 10/03/2017 01:49 PM, Andreas Glatz wrote:
> 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?
More information about the Xenomai