------- Comment #15 from mikedalpee at enginsol dot com 2010-09-03 00:24 ------- I have spent a lot more time playing around with this, and after running the exception1 program numerous times, the behaviour oscillates between working correctly or not working at all. So there appears to be some sort of race condition during the the stack unwinding process that results from a thread cancellation.
In particular, it does not appear that the thread is being reliably cancelled at the pthread_testcancel call - sometimes f2 seems to run beyond the pthread_testcancel, which causes the throw to execute, and results in an abort (seems to want to act like an uncaught exception propagated out). If you comment out the throw, f2 will sometimes continue to construct additional objects past 50. I have also noticed that sometimes a bunch of the Y objects get destructed, but then the program suddenly summarily exits. I also tried setting the cancellation type to asynchronous, but that doesn't make any difference - sometimes it works, sometimes it don't. Its very unpredictable. In any case, I need someone to tell me if this is the appropriate place to have aired this particular bug, or would it be better placed in the glibc bugzilla. I really do need this to work reliably so my 400K+ SLOC port can have a chance to work without requiring a major redesign of the underlying thread framework. FYI, this has been working flawlessly under Solaris/Sun Studio C++ for the last 10 years. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479