[Bug c++/45479] Exceptions not delivered properly after thread cancellation

[redi at gcc dot gnu dot org]

------- Comment #17 from redi at gcc dot gnu dot org  2010-09-10 10:11 -------
(In reply to comment #15)
> 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,

As I said above, that's consistent with f2(50) executing before pthread_cancel.

> 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 think that's because f2(50) leaves cancellation enabled and writing to cout
is a cancellation point, so the exit happens when some ~Y destructor coincides
with thread2 calling pthread_cancel.

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

Yes, race conditions tend to have unpredictable results.

If I change the condition in f2 to (i >= 50) and disable cancellation again
after the call to pthread_testcancel then I get more predictable behaviour,
because that ensures that the only cancellation points are the calls to
pthread_testcancel in f2, which still occur in f2(51), f2(52) etc. i.e.
cancellation still occurs at the intended place even if f2(50) happens before
the call to pthread_cancel.   That seems to validate my theory that the cancel
happens after f2(50), and so takes effect at the first cancellation point after
the cancellation request.

I don't think there's a gcc or glibc bug here, just non-portable code with
indeterminate behaviour.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45479