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.
Created attachment 98594 [details] Program to demo failure
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.
*** Bug 186432 has been marked as a duplicate of this bug. ***
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.
(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.
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.