Anonymous | Login | 2024-11-13 16:30 UTC |
Main | My View | View Issues | Change Log | Docs |
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 | 2024-06-11 09:02 | ||
Reporter | dalias | View Status | public | ||||
Assigned To | |||||||
Priority | normal | Resolution | Accepted As Marked | ||||
Status | Closed | ||||||
Name | Rich Felker | ||||||
Organization | musl libc | ||||||
User Reference | |||||||
Section | abort | ||||||
Page Number | 560 | ||||||
Line Number | 19406-19414 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | Note: 0005851 | ||||||
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 | tc3-2008 | ||||||
Attached Files | |||||||
|
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 | => --- |
2022-05-12 15:29 | geoffclare | Tag Attached: c99 | |
2022-06-16 16:15 | geoffclare | Tag Detached: c99 | |
2022-06-16 16:22 | Don Cragun | Note Edited: 0002607 | |
2022-06-16 16:23 | Don Cragun | Note Edited: 0002607 | |
2022-06-17 14:22 | geoffclare | Note Added: 0005851 | |
2022-06-17 14:24 | geoffclare | Note Edited: 0005851 | |
2022-06-23 15:23 | geoffclare | Final Accepted Text | => Note: 0005851 |
2022-06-23 15:23 | geoffclare | Status | New => Resolved |
2022-06-23 15:23 | geoffclare | Resolution | Open => Accepted As Marked |
2022-06-23 15:23 | geoffclare | Tag Attached: tc3-2008 | |
2022-07-19 14:08 | geoffclare | Status | Resolved => Applied |
2024-06-11 09:02 | agadmin | Status | Applied => Closed |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |