Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
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
Reporter dalias View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Rich Felker
Organization musl libc
User Reference
Section abort
Page Number 560
Line Number 19406-19414
Interp Status ---
Final Accepted Text
Summary 0000906: Ambiguity of abort() behavior racing with sigaction
Description 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.
Desired Action 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.
Attached Files

- Relationships

-  Notes
(0002607)
Don Cragun (manager)
2015-03-26 15:38

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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker