POSIX signal handler can cause stack overflow when blocked

[Daniel Hellstrom]

The psxalarm test brought it to my attention. The psxalarm signal handler causes a stack overflow to happen when printf() is called from the handler.

It can be triggered on UP and SMP LEON3 or NGMP systems, more frequent on a slow UART. It also seems easier to trigger the case on systems with short console UART FIFO depth.

If the signal handler contains a blocking call it seems that when the task executing the handler is woken up again another stack frame with the same POSIX signal handler is called. Now that handler will make the same blocking call, when woken up again another stack frame is added and so on. Eventually a stack overflow occurs.

This behaviour seems to be present since 4.10 at least.

[Sebastian Huber]

This is a known problem (or feature?) of the signal implementation. In case you call _Thread_Dispatch() in a signal handler, this is a recursion.

[Gedare Bloom]

If we don't fix it, then it should be documented.

[Sebastian Huber]

Its possible to fix this, but it has absolutely no priority for me. The signals are a questionable concept in general on a real-time system.

[Gedare Bloom]

A lot of embedded systems use signals pervasively in component-based software frameworks. Whether or not they achieve hard real-time guarantees is questionable. However, POSIX compliance should not mean RTEMS provides features that are not properly documented in how to use them.

I appreciate the lack of priority for fixing this. We should document it (somewhere related to signals in the POSIX manual) and move on for now, but leave the ticket open and bump the milestone to 5.0.

[Gedare Bloom]

bump milestone

[Gedare Bloom]

adjust from 5.0 to 4.11.1