Austin Group Defect Tracker

Aardvark Mark IV

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
0000614 [1003.1(2008)/Issue 7] System Interfaces Editorial Clarification Requested 2012-09-24 22:08 2024-06-11 08:52
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Rich Felker
Organization musl libc
User Reference
Section XSH 2.9.5
Page Number unknwon
Line Number unknown
Interp Status ---
Final Accepted Text Note: 0005939
Summary 0000614: Behavior of close() as a cancellation point is unspecified
Description For applications to correctly use cancellation, it's essential to know, when a function is cancelled, whether any or all of the function's side effects have taken place. For instance, if open is cancelled, it is important to know that a file descriptor was not allocated (which would inherently be a leak, since it's never returned to the caller). The standard handles this issue with the following text in XSH 2.9.5 under "Cancellation Points":

"The side-effects of acting upon a cancellation request while suspended during a call of a function are the same as the side-effects that may be seen in a single-threaded program when a call to a function is interrupted by a signal and the given function returns [EINTR]. Any such side-effects occur before any cancellation cleanup handlers are called."

However, this is not sufficient to define the behavior of close(), since:

"If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified."

(From the specification of close().)

This leaves an extremely dangerous situation where an application cancelled during close() cannot determine whether the file descriptor is still valid (and needs to be closed in the cleanup handler to avoid a leak) or already closed (in which case, closing it again in the cleanup handler would be dangerous because another thread could have raced to obtain a new file descriptor with the same numeric value).
Desired Action My preference would be to add after the cited text from 2.9.5, "If cancellation is acted upon as a result of a call to close, no side effects of the close function shall have taken place." If this condition is too strong, perhaps language could be added to allow that the file descriptor may be in a state where it is not useful except to pass to close() again.

If there's an unwillingness to clarify the requirements on implementations, then "application usage" language should be added to the standard to make explicit the fact that applications which fail to block cancellation (with pthread_setcancelstate) around calls to close have unspecified behavior upon cancellation.
Tags issue8
Attached Files

- Relationships
related to 0000529Closedajosey fildes unspecified on close()'s [EINTR] 
related to 0000632Closedajosey Side effects of pclose on cancellation are not specified 

-  Notes
(0001375)
eblake (manager)
2012-09-24 22:17

 This is probably a duplicate of 0000529, where the solution chosen there was to declare that close() must close the file descriptor unless it fails with EINTR, in which case it must leave the file descriptor open.
(0001376)
dalias (reporter)
2012-09-25 02:48

 I agree that the final accepted text for 0000529 resolves this issue as well and matches my first choice of desired action. The fact that it does so suggests to me that the right decision was made on that issue, despite it being controversial at the time.
(0001377)
eblake (manager)
2012-09-25 15:51

 Then again, the text for 529 did not mention posix_close() as a cancellation point, which means it is incomplete, so there is still work to do for specifying how close() and posix_close() interact with cancellation.
(0001380)
dalias (reporter)
2012-09-26 02:16

 It seems also to have failed to mention posix_close as an async-signal-safe function.
(0005939)
geoffclare (manager)
2022-08-22 16:13

 On D2.1 page 483 line 16985 section 2.4.3 add posix_close() to the list of async-signal-safe functions.

On D2.1 page 506 line 17923 section 2.9.5.2 add posix_close() to the "shall" cancellation point list.

- Issue History
Date Modified Username Field Change
2012-09-24 22:08 dalias New Issue
2012-09-24 22:08 dalias Status New => Under Review
2012-09-24 22:08 dalias Assigned To => ajosey
2012-09-24 22:08 dalias Name => Rich Felker
2012-09-24 22:08 dalias Organization => musl libc
2012-09-24 22:08 dalias Section => XSH 2.9.5
2012-09-24 22:08 dalias Page Number => unknwon
2012-09-24 22:08 dalias Line Number => unknown
2012-09-24 22:17 eblake Note Added: 0001375
2012-09-24 22:17 eblake Relationship added related to 0000529
2012-09-25 02:48 dalias Note Added: 0001376
2012-09-25 15:51 eblake Note Added: 0001377
2012-09-26 02:16 dalias Note Added: 0001380
2012-11-28 17:37 nick Relationship added related to 0000632
2022-08-22 16:13 geoffclare Note Added: 0005939
2022-08-22 16:13 geoffclare Interp Status => ---
2022-08-22 16:13 geoffclare Final Accepted Text => Note: 0005939
2022-08-22 16:13 geoffclare Status Under Review => Resolved
2022-08-22 16:13 geoffclare Resolution Open => Accepted As Marked
2022-08-22 16:14 geoffclare Tag Attached: issue8
2022-09-27 15:29 geoffclare Status Resolved => Applied
2024-06-11 08:52 agadmin Status Applied => Closed

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