#2263 assigned defect

POSIX signal handler can cause stack overflow when blocked

Reported by: Daniel Hellstrom Owned by: Needs Funding
Priority: normal Milestone: Indefinite
Component: unspecified Version: 4.10
Severity: normal Keywords:
Cc: Blocked By:


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.

Change History (8)

comment:1 Changed on 02/12/15 at 09:02:11 by 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.

comment:2 Changed on 02/12/15 at 14:06:29 by Gedare Bloom

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

comment:3 Changed on 02/12/15 at 14:16:20 by 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.

comment:4 Changed on 02/12/15 at 14:41:25 by 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.

comment:5 Changed on 03/02/15 at 20:50:26 by Gedare Bloom

Milestone: 4.115.0

bump milestone

comment:6 Changed on 03/02/15 at 20:50:59 by Gedare Bloom


adjust from 5.0 to 4.11.1

comment:7 Changed on 01/26/17 at 07:16:00 by Sebastian Huber


comment:8 Changed on 02/15/17 at 13:14:08 by Sebastian Huber

Milestone: 4.11.2Indefinite
Owner: set to Needs Funding
Status: newassigned
Note: See TracTickets for help on using tickets.