Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000610 [1003.1(2008)/Issue 7] System Interfaces Objection Clarification Requested 2012-09-24 20:17 2012-09-24 20:17
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Open  
Status Under Review  
Name Rich Felker
Organization musl libc
User Reference
Section exit
Page Number unknown
Line Number unknown
Interp Status ---
Final Accepted Text
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 No tags attached.
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
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


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker