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
0000622 [1003.1(2008)/Issue 7] System Interfaces Objection Omission 2012-10-15 00:26 2014-06-05 15:49
Reporter dalias View Status public  
Assigned To ajosey
Priority normal Resolution Accepted As Marked  
Status Resolved  
Name Rich Felker
Organization musl libc
User Reference
Section XSH 2.9.5 Thread Cancellation
Page Number 295
Line Number 17659-17673
Interp Status ---
Final Accepted Text See Note: 0002261.
Summary 0000622: Disallow loophole for asynchronous cancellation of any function
Description It's clearly the intent of the standard that implementations need not guard against asynchronous cancellation in functions which are not specified to be async-cancel-safe. However, interaction of asynchronous signals and cancellation seems to make it possible for a conforming program to initiate asynchronous cancellation during any function. Consider the following program:

#include <pthread.h>
#include <signal.h>
#include <unistd.h>

void *f(void *p) { for (;;) free(malloc(1)); }
void handler(int s) { close(-1); }

int main()
{
    pthread_t t;
    signal(SIGINT, handler);
    pthread_create(&t, 0, f, 0);
    sleep(1);
    pthread_cancel(t);
    pthread_kill(t, SIGINT);
    /* expect allocator state possibly inconsistent past this point... */
    pthread_join(t, 0);
}

Note here that close(-1) is being used as an async-signal-safe version of pthread_testcancel(); several other functions would work in its place.
Desired Action Add text to the effect that if an application causes cancellation to be acted upon while an async-signal-unsafe (or async-cancel-unsafe?) function is interrupted by a signal handler, the behavior is undefined. Also add application usage notes that applications which use cancellation should take appropriate precautions when handling signals - either blocking signals in threads that could be subject to cancellation, or ensuring that no cancellation points are invoked from signal handlers when cancellation is enabled. My proposed action for #615 would make this easier for applications, and I don't believe it would impose any burden on implementations.
Tags tc2-2008
Attached Files

- Relationships
related to 0000841Resolvedajosey pthread_setcancelstate should be async-signal-safe 
related to 0000615Interpretation Requiredajosey pthread_setcancelstate should be async-signal-safe 

-  Notes
(0002260)
geoffclare (manager)
2014-06-05 14:47
edited on: 2014-06-05 14:50

The following part of the 0000841 resolution should be done in this bug instead (so that it can be included in TC2):

At page 515 line 17840 section 2.9.5.4 Async-Cancel Safety add two paragraphs:
If a thread has asynchronous cancellation enabled and is cancelled during execution of a function that is not async-cancel-safe, the behavior is undefined.

If a thread has deferred cancellation enabled, a signal catching function is called in that thread during execution of a function that is not async-cancel-safe, and the signal catching function calls any function that is a cancellation point while a cancellation is pending for the thread, without first disabling cancellation, the behavior is undefined.


but minus the words "without first disabling cancellation", which 0000841 can then add for Issue 8.

(0002261)
Don Cragun (manager)
2014-06-05 15:46

At page 515 line 17840 section 2.9.5.4 Async-Cancel Safety add two paragraphs:

If a thread has asynchronous cancellation enabled and is cancelled during execution of a function that is not async-cancel-safe, the behavior is undefined.

If a thread has deferred cancellation enabled, a signal catching function is called in that thread during execution of a function that is not async-cancel-safe, and the signal catching function calls any function that is a cancellation point while a cancellation is pending for the thread, the behavior is undefined.

Change "None." at page 1694, line 54327 section APPLICATION USAGE in pthread_setcancelstate() to:

In order to write a signal handler for an asynchronous signal which can run safely in a cancellable thread, pthread_setcancelstate() must be used to disable cancellation for the duration of any calls that the signal handler makes which are cancellation points. However, the standard does not permit strictly conforming applications to call pthread_setcancelstate() from a signal handler since it is not currently required to be async-signal-safe. On implementations where pthread_setcancelstate() is not async-signal-safe, alternatives are to ensure either that the corresponding signals are blocked during execution of functions that are not async-cancel-safe or that cancellation is disabled during times when those signals could be delivered. Implementations are strongly encouraged to make pthread_setcancelstate() async-signal-safe.

- Issue History
Date Modified Username Field Change
2012-10-15 00:26 dalias New Issue
2012-10-15 00:26 dalias Status New => Under Review
2012-10-15 00:26 dalias Assigned To => ajosey
2012-10-15 00:26 dalias Name => Rich Felker
2012-10-15 00:26 dalias Organization => musl libc
2012-10-15 00:26 dalias Section => XSH 2.9.5 Thread Cancellation
2012-10-15 00:26 dalias Page Number => unknown
2012-10-15 00:26 dalias Line Number => unknown
2013-04-25 16:19 Don Cragun Relationship added related to 0000615
2013-05-02 15:40 msbrown Interp Status => ---
2013-05-02 15:40 msbrown Summary Disallow loophope for asynchronous cancellation of any function => Disallow loophole for asynchronous cancellation of any function
2014-06-05 14:47 geoffclare Note Added: 0002260
2014-06-05 14:48 geoffclare Relationship added related to 0000841
2014-06-05 14:50 geoffclare Note Edited: 0002260
2014-06-05 15:46 Don Cragun Note Added: 0002261
2014-06-05 15:49 Don Cragun Page Number unknown => 295
2014-06-05 15:49 Don Cragun Line Number unknown => 17659-17673
2014-06-05 15:49 Don Cragun Final Accepted Text => See Note: 0002261.
2014-06-05 15:49 Don Cragun Status Under Review => Resolved
2014-06-05 15:49 Don Cragun Resolution Open => Accepted As Marked
2014-06-05 15:50 Don Cragun Tag Attached: tc2-2008


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