[Xenomai] any extra reasons for -EINTR in xenomai

Philippe Gerum rpm at xenomai.org
Fri Mar 3 16:57:04 CET 2017


On 03/03/2017 03:18 PM, Henning Schild wrote:
> Hi,
> 
> someone came to me asking about reasons why system calls would exit
> with -EINTR on a xenomai 2 system. As far as i know there a are two
> possible reasons for that to happen.
> 1. the thread received a signal while being blocked in the call
> 2. the thread got a rt_task_unblock
> 
> Now we are pretty sure that we can rule out both of these cases. It is
> a complex system and there might be signals. But none of the
> applications signal handlers was called and the application did not
> exit, which only leaves very few signals as candidates. Because almost
> all default signal handlers will end an application.
> And my current assumption would be that default signal handlers
> all have SA_RESTART and there would be no -EINTR. Which limits the
> possible signals to the ones where a custom handler was installed and
> SA_RESTART was not set. But according to the logs no custom handler was
> called.
> 
> We know it happened while being blocked in rtdm_event_timedwait and the
> documentation mentions the two reasons from above.
> 

Somebody has to raise the XNBREAK bit in the tcb for this to happen,
i.e. xnthread_set_info(thread, XNBREAK). There are four locations in the
nucleus doing that, two of them happen in do_sigwake_event(). Tracing
there would rule out the consequence of receiving a regular signal.

In a related case, entering xnpod_suspend_thread() in a runnable state
with the XNKICKED bit set would also cause the XNBREAK bit to be set,
preventing the caller to block. This should only happen if a signal is
raised from another CPU while the caller is traversing the Xenomai
syscall path.

Finally, there is xnpod_unblock_thread() but that one won't be called
unless the application forcibly unblocks a thread, which you already
ruled out.

-- 
Philippe.



More information about the Xenomai mailing list