------- 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

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.



Reply via email to