Bug 118490 - exception not rethrown error on deferred thread cancelation
exception not rethrown error on deferred thread cancelation
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
athlon Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
: Reopened
: 186432 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-16 19:17 EST by Gav Wood
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:28:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Program to demo failure (1.10 KB, text/plain)
2004-03-16 19:17 EST, Gav Wood
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 28145 None None None Never

  None (edit)
Description Gav Wood 2004-03-16 19:17:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)

Description of problem:
on cancellation/exitting of a thread a fatal exception error is given:

take two threads, A & B and a mutex M and condition C: 
 
A aquires M, sleeps for two seconds then frees M and exits normally. 
B aquires M, then waits on C indefinately. 
main() starts A, then B, sleeps for a second, then cancels/joins B, then cancels A, if still running. 
 
what should happen: 
0. both threads start 
1. A aquires M; B blocks, waiting for M to become unlocked. 
2. B is cancelled, which is deferred, blocking main(). 
3. A unlocks M. 
4. A exits; B aquires M, blocks on C indefinately. 
5. B, having reached a cancellation point is cancelled. 
6. Program exits. 
 
what actually happens: 
0-3. Correct. 
4. Error given immediately after A's "main" function is exitted 
"FATAL: exception not rethrown". Program immediately aborts. 
 


Version-Release number of selected component (if applicable):
glibc-2.3.3pre-20040207

How reproducible:
Always

Steps to Reproduce:
1. Compile attached program with g++ test.cpp -lpthread
2. Run with ./a.out
3. There is no step 3
    

Actual Results:  A: Locking M
A: Sleeping...
B: Locking M
Cancelling B.
Waiting for B to finish.
A: Unlocking M
FATAL: exception not rethrown
B: Waiting on C
Aborted


Expected Results:  A: Locking M
A: Sleeping...
B: Locking M
Cancelling B.
Waiting for B to finish.
A: Unlocking M
B: Waiting on C
B: Cleaning up
B: Done
Cancelling A.

Additional info:

i'm having trouble getting gdb to function correctly, so i cant 
really give an accurate backtrace.
Comment 1 Gav Wood 2004-03-16 19:17:52 EST
Created attachment 98594 [details]
Program to demo failure
Comment 2 Jakub Jelinek 2004-03-17 04:01:21 EST
Thanks.
This testcase is a nice example of the unsolved catch (...) vs. cancellation
problem.
See http://www.codesourcery.com/archives/c++-pthreads/threads.html
and http://gcc.gnu.org/ml/gcc/2003-12/msg00743.html
and following thread.
Until this is resolved, and some people try very hard to make sure
it is never resolved, this will not work.  For the time being you can
just temporarily disable cancellation around STL calls which can execute
cancellation points (this is all cout << ... << endl; in your testcase)
and enable afterwards.
Comment 6 Jakub Jelinek 2006-03-24 06:24:51 EST
*** Bug 186432 has been marked as a duplicate of this bug. ***
Comment 7 Jason Merrill 2007-04-13 15:51:07 EDT
I have patches for various approaches to fixing this problem in the gcc bugzilla
entry:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28145

I think the patch to allow explicit catching of __forced_unwind is
uncontroversial, and will allow people to work around this problem by inserting
an explicit catch and rethrow wherever a catch (...) might catch a forced
unwind.  This should go into upstream GCC soon, and would be trivial to backport
to Red Hat gcc releases.  However, this is insufficient to solve the iostream
problem; we would need to update all of the iostreams functions which use catch
(...) as mentioned above.

I would also like the NPTL patch, or similar, to go into glibc.  It changes
unwind_cleanup to clear EXITING_BIT so that the next cancellation point will
start exiting again.  This seems entirely safe and clean to me, and solves the
iostream problem (and many other instances of this abort) with no modifications
to user code.
Comment 8 Ulrich Drepper 2007-04-13 23:56:35 EDT
(In reply to comment #7)
> I think the patch to allow explicit catching of __forced_unwind is
> uncontroversial,

It is not uncontroversial if it does not include the requirement to rethrow the
exception.

> I would also like the NPTL patch, or similar, to go into glibc.  It changes
> unwind_cleanup to clear EXITING_BIT so that the next cancellation point will
> start exiting again.

How can you bring this up again?  This is not acceptable.  Cancellation is
terminal, it has always been and will always be.

Comment 9 RHEL Product and Program Management 2007-10-19 15:28:48 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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