Mike Dalpee <mikedalpee@xxxxxxxxxxxx> writes: > 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. Thanks for the test cases. I see this as well. As you know, pthread_cancel is implemented by raising an exception in the thread being cancelled. The behaviour matches a comment in libstdc++-v3/libsupc++/eh_personality.cc: // ??? How do foreign exceptions fit in? As far as I can // see we can't match because there's no __cxa_exception // object to stuff bits in for __cxa_call_unexpected to use. // Allow them iff the exception spec is non-empty. I.e. // a throw() specification results in __unexpected. A "foreign" exception is an exception that is not created by C++ code. I think this has to be described as a bug but I think it could be quite difficult to fix. Normally a function with an empty throw specification can not throw an exception, and it is possible that calling code is optimized under that assumption. > 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. I see this failure as well. As you say, the relevant comment is in libstdc++-v3/libsupc++/eh_catch.cc: // Foreign exceptions can't be stacked here. If the exception stack is // empty, then fine. Otherwise we really have no choice but to terminate. // Note that this use of "header" is a lie. It's fine so long as we only // examine header->unwindHeader though. In this case there is an exception stacked--the 1 thrown by ThreadRun. This is another bug, and it looks like it might also be hard to fix. Sorry to not have any useful information here. Basically, I think you've found bugs, and I don't think they will be fixed anytime soon. Ian
