View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000610 | 1003.1(2008)/Issue 7 | System Interfaces | public | 2012-09-24 20:17 | 2024-06-11 08:52 |
| Reporter | dalias | Assigned To | ajosey | ||
| Priority | normal | Severity | Objection | Type | Clarification Requested |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Rich Felker | ||||
| Organization | musl libc | ||||
| User Reference | |||||
| Section | exit | ||||
| Page Number | unknown | ||||
| Line Number | unknown | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0000610:0005947 | ||||
| Summary | 0000610: Possible race condition in requirements of exit and their interaction with threads. | ||||
| Description | As written, the specification of exit(), derived from C99 which lacks any notion of threads, makes no requirements on atomicity between closing open streams and terminating the process. As such, there is a possible race condition, which seems unintended, during which any other thread using stdio could attempt to access an already-closed file before termination occurs, invoking undefined behavior. Under this interpretation, it is unsafe for any multi-threaded process to ever call exit() (or return from the initial invocation of main()) without first taking action to ensure that no thread is in a state where it could attempt to access stdio. This is contrary to the intention that threads be usable transparently as an implementation detail in libraries. | ||||
| Desired Action | Please clarify whether it is the intent of the standard to permit implementations where this race condition exists. If so, I believe it calls for an explicit statement of the danger and application usage text suggesting how to avoid the problem. I have not yet spent time figuring out what the right warning text would be, or where it would belong, because I believe this is the wrong solution. If on the other hand I'm correct and the race condition is not intended to be permitted, the specification of exit() should be amended to clarify this, perhaps by replacing the text: The exit() function shall then flush all open streams with unwritten buffered data and close all open streams. Finally, the process shall be terminated with the same consequences as described in Consequences of Process Termination. with: The exit() function shall then flush all open streams with unwritten buffered data. For each stream which is the active handle to its underlying file descriptor, and for which the file is capable of seeking, the file offset of the underlying open file description shall be set to the file position of the stream. Finally, the process shall be terminated with the same consequences as described in Consequences of Process Termination. In other words, remove the requirement that the stream be "closed" (which presumably means "as if by fclose") and instead just require the equivalent side effects. Note that I based the above text on the revised text for fclose from issue #87 in the defect tracker rather than the text in the published standard; it should be checked for correctness. Alternatively, it may suffice to merely specify that the closing of streams is atomic with respect to program termination, i.e. that applications cannot observe a state where the streams have been closed. | ||||
| Tags | tc3-2008 | ||||
|
|
On 2018 edition page 796 line 27070, change:The exit() function shall then flush all open streams with unwritten buffered data and close all open streams. Finally, the process shall be terminated [CX]with the same consequences as described in [xref to Consequences of Process Termination][/CX].to: The exit() function shall then flush all open streams with unwritten buffered data. [CX]For each stream which is the active handle to its underlying file descriptor, and for which the file is not already at EOF and is capable of seeking, the file offset of the underlying open file description shall be set to the file position of the stream. For each open stream, the exit() function shall perform the equivalent of a close() on the file descriptor that is associated with the stream.[/CX] Finally, the process shall be terminated [CX]with the same consequences as described in [xref to Consequences of Process Termination][/CX]. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-09-24 20:17 | dalias | New Issue | |
| 2012-09-24 20:17 | dalias | Status | New => Under Review |
| 2012-09-24 20:17 | dalias | Assigned To | => ajosey |
| 2012-09-24 20:17 | dalias | Name | => Rich Felker |
| 2012-09-24 20:17 | dalias | Organization | => musl libc |
| 2012-09-24 20:17 | dalias | Section | => exit |
| 2012-09-24 20:17 | dalias | Page Number | => unknown |
| 2012-09-24 20:17 | dalias | Line Number | => unknown |
| 2022-08-25 16:29 | geoffclare | Note Added: 0005947 | |
| 2022-08-25 16:30 | geoffclare | Interp Status | => --- |
| 2022-08-25 16:30 | geoffclare | Final Accepted Text | => 0000610:0005947 |
| 2022-08-25 16:30 | geoffclare | Status | Under Review => Resolved |
| 2022-08-25 16:30 | geoffclare | Resolution | Open => Accepted As Marked |
| 2022-08-25 16:31 | geoffclare | Tag Attached: tc3-2008 | |
| 2022-09-27 15:20 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 08:52 | agadmin | Status | Applied => Closed |
