Ian, I was able to create some small test cases that demonstrate the problem. Unfortunately, the computers I used to do this have no internet access and I am not allowed to take media out of the building. I will try to get a printout I can scan or type in, but in the meantime, here are the salient features of the test cases. There are two cases I uncovered that result in aborts: 1) Cancelling a thread that is in a function that has an empty throw clause (throw()). The runtime appears to treat abi::__forcedUnwind as an unexpected exception and the following message appears on the console: terminate called without an active exception If the throw clause names any exception (i.e, is not empty) or has not throw clause at all, no abort occurs. 1) Cancelling a thread that is already in an exception handler and then attempting to rethrow abi:: __forcedUnwind. The runtime appears to treat the rethrow as a "stacked foreign exception" (from comments in the relevant libsup++ code.) I set up this circumstance by throwing an int and then calling a function in the exception handler (for int) that sits at a cancellation point. The following message appears on the console: terminate called after throwing an instance of 'int' If the rethrow of abi:: __forcedUnwind is removed, no abort occurs. Let me know if I can provide any more info. Regards, Mike ________________________________________ From: Ian Lance Taylor [iant@xxxxxxxxxx] Sent: Tuesday, May 08, 2012 1:35 AM To: Mike Dalpee Cc: gcc-help@xxxxxxxxxxx Subject: Re: GCC 4.6.2 C++ thread cancellation issue Mike Dalpee <mikedalpee@xxxxxxxxxxxx> writes: > The system is RHEL 6.1 X86_64, using glibc 2.12 that comes with the system. I was going to give GCC 4.7 a try, but unfortunately, they closed a very arcance template dependent name resolution loophole that my 3rd-party legacy code was exploiting and it will be a bear to try to fix it. > > Threads are being cancelled using libpthread pthread_cancel, synrchonously I believe - will have to verify that. > > So perhaps going to a later version of glibc might be worth a try? I see 2.15 is the latest. If so, do you know what special build options I must chose to make the exception handling work correctly? glibc 2.12 is sufficiently recent that I would not expect upgrading to the latest glibc to help. Do you have a small single file test case? Ian > ________________________________________ > From: Ian Lance Taylor [iant@xxxxxxxxxx] > Sent: Monday, May 07, 2012 6:40 PM > To: Mike Dalpee > Cc: gcc-help@xxxxxxxxxxx > Subject: Re: GCC 4.6.2 C++ thread cancellation issue > > Mike Dalpee <mikedalpee@xxxxxxxxxxxx> writes: > >> I am trying to port some legacy code to properly work in the face of >> thread cancellation. > > What thread library are you using? E.g., are you using glibc on a > GNU/Linux system, or something else? > > How are you cancelling the thread? Via pthread_cancel or something > else? > > Are you using an ARM system or something else? > > >> Based on information I have gleaned from searching the net, it appears >> that any catch(...) handlers that try to finalize the exception must >> be augmented to first catch abi::_forced_unwind and simply rethrow the >> exception for cancellation to work properly. > > That seems plausible, assuming you use a simple "throw;" to rethrow the > exception. > > >> I am running into a problem where the rethrow of abi::_forced_unwind >> is being treated as an unhandled exception by the runtime, thereby >> causing an abort to occur. So, my questions are: >> >> 1) Should what I am doing work? > > Ideally, yes. > >> 2) Is there a particular way GCC must be built for the rethrow to work? > > No. > >> 3) Is there a particular combination of GCC/GLIBC versions required >> for the rethrow to work? > > The GCC version shouldn't matter. The way that GLIBC was built does > matter. > > Ian
