Bug 111538 - pthread canceltype changed after cancellation while blocked in a syscall
pthread canceltype changed after cancellation while blocked in a syscall
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-04 17:53 EST by Davide Guerri
Modified: 2016-11-24 10:01 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-08 04:43:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test program for the bug. (1.47 KB, text/plain)
2003-12-04 17:57 EST, Davide Guerri
no flags Details
Test program for the bug. (1.76 KB, text/plain)
2003-12-04 17:59 EST, Davide Guerri
no flags Details
Test program for the bug. (2.45 KB, text/plain)
2003-12-05 04:16 EST, Davide Guerri
no flags Details

  None (edit)
Description Davide Guerri 2003-12-04 17:53:17 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1)

Description of problem:
(sorry for my horrible English) 
If a thread is cancelled when is blocked in a syscall or in pthread_cond_timedwait(), its cancellation type is modified in PTHREAD_CANCEL_ASYNCHRONOUS even if its previous type was PTHREAD_CANCEL_DEFERRED. 
The problem verifyes also when pthread_cond_timedwait() is interrupted by a pthread_cond_signal() call.


Version-Release number of selected component (if applicable):
glibc-2.3.2-27.9.7

How reproducible:
Always

Steps to Reproduce:
1. Compile the test programs below
2. Execute the programs
3. Evaluate the results
    

Actual Results:  Before calling sleep() the cancel type of the thread is deferred, after the cancellation, while blocked in sleep(), the cancel type is changed in asynchronous.

Before calling pthread_cond_timedwait() the cancel type of the thread is deferred, after a pthread_cond_signal() the cancel type of the thread is changed in asynchronous.

Expected Results:  In both cases the cancel type should remain deferred.

Additional info:
Comment 1 Davide Guerri 2003-12-04 17:57:23 EST
Created attachment 96357 [details]
Test program for the bug.
Comment 2 Davide Guerri 2003-12-04 17:59:30 EST
Created attachment 96358 [details]
Test program for the bug.
Comment 3 Ulrich Drepper 2003-12-04 18:01:48 EST
And where exactly does the POSIX specification support this claim of
yours?
Comment 4 Davide Guerri 2003-12-04 18:04:34 EST
Temporary workarounds: 
 
void __resetCancelType(void *dummy) 
{ 
   pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL); 
} 
 
unsigned int ef_sleep(unsigned int seconds) 
{ 
   unsigned int retVal; 
 
   pthread_cleanup_push(__resetCancelType, NULL); 
   retVal = sleep(seconds); 
   pthread_cleanup_pop(0); 
   return retVal; 
} 
 
int ef_pthread_cond_timedwait(pthread_cond_t * cond, pthread_mutex_t 
* mutex, const struct timespec *abstime) 
{ 
   int retVal; 
 
   pthread_cleanup_push(__resetCancelType, NULL); 
   retVal = pthread_cond_timedwait(cond, mutex, abstime); 
   pthread_cleanup_pop(1); 
   return retVal; 
} 
 
[...] 
Comment 5 Davide Guerri 2003-12-04 18:08:16 EST
I'm not sure that posix specifies anyting about it, but the 
behaviour should be the same always, while the problem doesn't 
appear when blocked in pthread_cond_wait() (for instance) 
Comment 6 Davide Guerri 2003-12-04 18:10:57 EST
And what about the behaviour of the thread when leaving timedwait 
after a signal? 
Comment 7 Davide Guerri 2003-12-04 19:50:02 EST
(I know my English is horrible, but let me try to explain this) 
If POSIX doesn't specify anything about the cancellation type after 
a cancel, and you decided to set it to PTHREAD_CANCEL_ASYNCHRONOUS, 
there is a problem: 
If one calls pthread_exit() the cancellation type remain unchanged 
while the execution of cleanup handlers.  
If the cleanup handler is executed due to a pthread_cancel() while 
we're blocked in a syscall, the cancellation type change to 
asynchronous. 
The pthread_cancel() man page says that pthread_cancel() should have 
the same effect of a call to pthread_exit(PTHREAD_CANCELED). (Is 
this a POSIX specification?) 
If a developer can't know if the cleanup handler is called due to a 
cancellation or a pthread_exit() (and therefore the cancellation 
type of the thread is unknown) he/she can't make any assumption. 
 
Comment 8 Davide Guerri 2003-12-05 04:15:45 EST
Test program that exibit the behaviour i stated above. 
 
On my system the output is this: 
--------------------------------------- 
[tato@Gohan a]$ ./double_cancel 
1) 
Beacause in cleanup handler we invoke a syscall, the handler is 
executed two times: 
cleanup handler (begin) 
cancel type = asynchronous 
cleanup handler (end) 
cleanup handler (begin) 
cancel type = asynchronous 
cleanup handler (end) 
 
2) 
This time the thread calls pthread_exit(PTHREAD_CANCELED) and the 
cleanup handler is executed three times. 
Moreover the first execution is interrupted by the second: 
cleanup handler (begin) 
cancel type = deferred 
cleanup handler (begin) 
cancel type = asynchronous 
cleanup handler (end) 
cleanup handler (begin) 
cancel type = asynchronous 
cleanup handler (end) 
Bye! 
--------------------------------------- 
 
This example arises another problem: how many times a cleanup 
handler will be executed? Will it be interrupted and restarted in 
case of cancellation (see step 2) )? 
 
If the behaviour were "unspecified" the documentation should state 
that one could not use syscalls in (or as) cleanup handlers. 
But in the pthread_cleanup_push() man page is stated: 
<<Cleanup  handlers  can  be used similarly to free blocks allocated 
with malloc(3) or close file descriptors on thread termination.>> 
Unfortunately close() is a syscall... 
 
I know that this problem is solved using 
"pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &oldstate)" in the 
handler, but what if we use directly a library function (that invoke 
internally a syscall) for cleanup handler? 
Comment 9 Davide Guerri 2003-12-05 04:16:38 EST
Created attachment 96367 [details]
Test program for the bug.
Comment 10 Davide Guerri 2003-12-06 04:27:51 EST
In reply to Ulrich Drepper. 
In the rationale section 
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_setcancelstate.html 
says: 
<<...the cancelability type may be explicitly set to either deferred 
or asynchronous upon entry to an object. But as with the 
cancelability state, on exit from an object the cancelability type 
should always be restored to its value on entry to the object.>> 
 
Comment 11 Davide Guerri 2003-12-06 04:42:24 EST
Moreover, 
http://www.opengroup.org/onlinepubs/007904975/functions/pthread_cleanup_pop.html 
in the description section says: 
<< [...] 
The cancellation cleanup handler shall be popped from the 
cancellation cleanup stack and invoked with the argument arg when: 
 - The thread exits (that is, calls pthread_exit()). 
 - The thread acts upon a cancellation request. 
 - The thread calls pthread_cleanup_pop() with a non-zero execute 
argument. 
[...] >> 
 
So a cleanup handler should not be re-executed if a cancellation 
occours during its execution, because the handler should have been 
popped. 
Comment 12 Davide Guerri 2003-12-08 04:42:52 EST
I did a mess with this bug report. Sorry. 
There is no reason to pretend a predicible canceltype after a 
cancellation since in cleanup handlers the cancellation should be 
disabled. 
Moreover I think that there are two bugs not one: the problem with 
pthread_cond_timedwait() and the problem with cancellation cleanup 
handlers. 
I'll close this report and I'll create two separate (and less 
messed) bug reports. 
 
Comment 13 Davide Guerri 2003-12-08 05:02:15 EST
Sorry again, not "to pretend", "to require"... )); 

Note You need to log in before you can comment on or make changes to this bug.