|Anonymous | Login||2021-05-08 07:26 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000906||[1003.1(2013)/Issue7+TC1] System Interfaces||Editorial||Clarification Requested||2014-12-18 02:10||2015-03-26 15:41|
|Final Accepted Text|
|Summary||0000906: Ambiguity of abort() behavior racing with sigaction|
The abort function is specified to cause abnormal program termination with status indicating SIGABRT "unless the signal SIGABRT is being caught and the signal handler does not return", but the phrase "is being caught" is ambiguous with respect to concurrent changes to the signal disposition for SIGABRT from other threads. Moreover, the normal way of implementing the abnormal termination when a signal handler is installed is to reset the disposition to SIG_DFL if raising SIGABRT did not terminate the process already, but such an operation can contend with a call to sigaction from another thread that reinstalls a signal handler, thereby causing more than one signal handler to run as a result of the call to abort. Two implementations I examined (GNU and OpenBSD) use such an implementation approach and fail to address this in any meaningful way. Further, such implementations seem to be non-conforming since abort is not specified to change the signal disposition for SIGABRT (except possibly in the case where it's ignored, since abort "shall override blocking or ignoring") and an application could observe (from another thread) the change in signal disposition.
The only ways I can see to implement abort which are consistent with the current text of the standard are either:
1. With a mechanism to "stop the world" (halt all other threads) before actually performing the operations involved to implement abort in terms of well-known primitives like raise and sigaction, OR
2. With a system call that performs the equivalent of _exit but faking termination by signal.
Since I'm not aware of any historical implementations that use either method 1 or 2 above, I am inclined to think that the current requirements are contrary to existing practice and perhaps unintentional.
Relax the requirements of abort to agree with current practice, something along the lines of:
"If the signal disposition for SIGABRT is changed during the execution of abort(), it is unspecified whether or how many times SIGABRT is delivered, the disposition of SIGABRT during abort() is unspecified, and implementation-defined abnormal program termination shall occur unless SIGABRT is caught and the signal handler does not return."
Language should also be added allowing the abort() to reset the disposition of SIGABRT to SIG_DFL.
|Tags||No tags attached.|
Don Cragun (manager)
This will be forwarded to the ISO C Committee for consideration.
We agree that something probably needs to change, but POSIX is aligned with C on this issue.
|2014-12-18 02:10||dalias||New Issue|
|2014-12-18 02:10||dalias||Name||=> Rich Felker|
|2014-12-18 02:10||dalias||Organization||=> musl libc|
|2014-12-18 02:10||dalias||Section||=> abort|
|2014-12-18 02:10||dalias||Page Number||=> unknown|
|2014-12-18 02:10||dalias||Line Number||=> unknown|
|2015-03-26 15:38||Don Cragun||Note Added: 0002607|
|2015-03-26 15:41||Don Cragun||Page Number||unknown => 560|
|2015-03-26 15:41||Don Cragun||Line Number||unknown => 19406-19414|
|2015-03-26 15:41||Don Cragun||Interp Status||=> ---|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|