[Bug libstdc++/28145] New: libstdc++ and pthread cancellation are incompatible (at least with NPTL)

[Bug libstdc++/28145] New: libstdc++ and pthread cancellation are incompatible (at least with NPTL)

[drow at gcc dot gnu dot org]

(This is not a new problem, and everyone involved is familiar with it.  I was
just surprised not to find a record of it in bugzilla.)

On targets using a recent version of glibc and the NPTL threading package, if
you cancel a thread using pthread_cancel while it is writing to an ostream,
you'll get a fatal error and an abort from glibc.  The abort happens because
std::ostream::put uses catch(...), catches the cancellation exception, and does
not rethrow it.  You can write a nasty workaround for this, but I'm obviously
not going to recommend it:

int cancelled = 0;                                                              
try {                                                                           
 pthread_cleanup_push(something-to-set-cancelled);                              
  write()                                                                       
  pthread_cleanup_pop(discard-cleanups);                                        
} catch (...) {                                                                 
  if (cancelled) throw;                                                         
  normal-catch-handling;
}                                                                               

That would only work if there was nothing marked throw() on the way up, of
course.

This problem has been discussed at length on the c++-pthreads list, but I don't
think a consensus was really reached.


-- 
           Summary: libstdc++ and pthread cancellation are incompatible (at
                    least with NPTL)
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: drow at gcc dot gnu dot org
GCC target triplet: *-*-linux*


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

[Bug libstdc++/28145] libstdc++ and pthread cancellation are incompatible (at least with NPTL)

[mark at codesourcery dot com]

------- Comment #1 from mark at codesourcery dot com  2006-06-23 18:14 -------
Subject: Re:   New: libstdc++ and pthread cancellation
 are incompatible (at least with NPTL)

drow at gcc dot gnu dot org wrote:

> On targets using a recent version of glibc and the NPTL threading package, if
> you cancel a thread using pthread_cancel while it is writing to an ostream,
> you'll get a fatal error and an abort from glibc.

> This problem has been discussed at length on the c++-pthreads list, but I don't
> think a consensus was really reached.

I believe that to solve this particular problem, a possible compromise
might be:

(1) Give the thread-cancellation exception a well-known name.
(2) Permit catching that exception -- but only if it is rethrown.

The point of (2) is that it avoids the controversy about whether or not
you are permitted to catch, and then not rethrow, the exception.

Then, you could write:

  try {
    io ();
  } catch (__thread_cancel&) {
    throw;
  } catch (...) {
    /* Normal catch handling.  */
  }

That would provide a mechanism for making libstdc++ (and other
applications) cancel-safe.  It would still not solve the general
philosophical issues about whether or not you should be allowed to fail
to "eat" the cancellation exception, but I think it would be a step forward.

Another way to do this, instead of having a named exception, would be to
have a "__uncaught_cancellation()" function, similar to
"std::__uncaught_exception()".  Then, you would do:

  try {
    io ();
  } catch (...) }
    if (__uncaught_cancellation ())
      throw;
    /* Normal catch handling.  */
  }


-- 


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

[Bug libstdc++/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-24 01:43 -------
Actually I think the consensus was talk to the C++ and POSIX standards comittee
about this case. 

 It is not just libstdc++ that could cause problems but any program that uses
throw() or catch(...) {/* fall through */ }.

In fact I can come up with a simple C++ case which fails without using
libstdc++.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
            Summary|libstdc++ and pthread       |C++ (throw() and catch(...)
                   |cancellation are            |{/*  fall through */ } ) and
                   |incompatible (at least with |pthread cancellation are
                   |NPTL)                       |incompatible (at least with
                   |                            |NPTL)


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[drow at gcc dot gnu dot org]

------- Comment #3 from drow at gcc dot gnu dot org  2006-06-24 02:52 -------
No, that was not the consensus, and I reported this bug specifically because
the coding practices used in libstdc++ cause problems with cancellation...
progress was being made, the last time I read c++-pthreads, but trailed off.


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[mark at codesourcery dot com]

------- Comment #4 from mark at codesourcery dot com  2006-06-24 04:10 -------
Subject: Re:  C++ (throw() and catch(...) {/*  fall through
 */ } ) and pthread cancellation are incompatible (at least with NPTL)

drow at gcc dot gnu dot org wrote:
> ------- Comment #3 from drow at gcc dot gnu dot org  2006-06-24 02:52 -------
> No, that was not the consensus, and I reported this bug specifically because
> the coding practices used in libstdc++ cause problems with cancellation...
> progress was being made, the last time I read c++-pthreads, but trailed off.

I don't think it's necessary (or even useful) to wait for the standards
bodies to solve this problem.  In practice, the c++-pthreads discussion
died off, and the C++ POSIX reflector has had no activity since January.
 So, it's certainly going to be a while before we have standards
documents to rely upon.

However, we know that it should be possible to write cancel-safe C++
libraries (including, in particular, libstdc++); otherwise, it's hard to
use C++ in a multi-threaded application.  And, we know that we can do it
with a very simple hook: we just need a way to ask whether the current
thread is being cancelled.  GLIBC has lots of extensions; if we can have
__thread_cancelled(), we've got enough, without having to solve the
problem of whether or not it should be possible to catch (and not
rethrow) the thread-cancellation exception.  (I'd rather have a name for
the thread exception, as that seems more natural, but this is a
difference only of syntax; the hook function would be a perfectly
satisfactory way to make progress.)


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[pcarlini at suse dot de]

------- Comment #5 from pcarlini at suse dot de  2006-07-07 17:17 -------
(In reply to comment #4)
> However, we know that it should be possible to write cancel-safe C++
> libraries (including, in particular, libstdc++); otherwise, it's hard to
> use C++ in a multi-threaded application.  And, we know that we can do it
> with a very simple hook: we just need a way to ask whether the current
> thread is being cancelled.  GLIBC has lots of extensions; if we can have
> __thread_cancelled(), we've got enough, without having to solve the
> problem of whether or not it should be possible to catch (and not
> rethrow) the thread-cancellation exception.  (I'd rather have a name for
> the thread exception, as that seems more natural, but this is a
> difference only of syntax; the hook function would be a perfectly
> satisfactory way to make progress.)

FWIW my personal opinion about this issue, I concur. Now, assuming all the
knowledgeable people do indeed agree, is it really feasible to add such feature
to glibc? Is someone going to ask glibc maintainers opinion?


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcarlini at suse dot de


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at gcc dot gnu dot org]

------- Comment #6 from jason at gcc dot gnu dot org  2006-07-31 09:38 -------
Created an attachment (id=11978)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11978&action=view)
libstdc++ patch to allow catching forced unwind separately

Trying to move this issue forward: here's a libsupc++ patch that allows users
to detect forced unwind using a magic class.  This is a little ugly, as there
isn't actually an object for the catch parameter to bind to.  It should also be
discussed with the C++ ABI committee; I notice that the ABI EH document still
says  that you can't catch forced unwind (like Ada).


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at gcc dot gnu dot org]

------- Comment #7 from jason at gcc dot gnu dot org  2006-07-31 09:40 -------
Created an attachment (id=11979)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11979&action=view)
NPTL patch to allow discarding cancellation exception

And here's a completely untested patch to NPTL to implement the "sticky cancel"
semantics I've talked about; discarding the forced unwind exception causes the
exiting bit to be unset, so that the next cancellation point starts unwinding
again.


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at gcc dot gnu dot org]

------- Comment #8 from jason at gcc dot gnu dot org  2006-08-01 02:13 -------
Created an attachment (id=11985)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11985&action=view)
libstdc++ patch to prevent ... from catching forced unwird

Finally, this patch stops ... from catching forced unwind, as specified by the
ABI.

I think the catch (abi::__forced_unwind &) patch should be uncontroversial, and
works well with either solution to the catch (...) problem.


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at gcc dot gnu dot org]

------- Comment #9 from jason at gcc dot gnu dot org  2006-08-01 02:33 -------
Created an attachment (id=11986)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11986&action=view)
revision to forced-lib.patch that also adds __foreign_exception


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #11978|0                           |1
        is obsolete|                            |
         AssignedTo|unassigned at gcc dot gnu   |jason at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[drow at gcc dot gnu dot org]

------- Comment #10 from drow at gcc dot gnu dot org  2006-08-01 02:47 -------
Subject: Re:  C++ (throw() and catch(...) {/*  fall through */ } ) and pthread
cancellation are incompatible (at least with NPTL)

On Tue, Aug 01, 2006 at 02:13:08AM -0000, jason at gcc dot gnu dot org wrote:
> Finally, this patch stops ... from catching forced unwind, as specified by the
> ABI.

Just making sure I understand - catch (...) { foo(); throw; } will no
longer call foo during forced unwinding, only destructors and explicit
forced unwinding catches will be called?

[What does this imply for throw()?]


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at redhat dot com]

------- Comment #11 from jason at redhat dot com  2006-08-01 07:10 -------
Subject: Re:  C++ (throw() and catch(...) {/*  fall through
 */ } ) and pthread cancellation are incompatible (at least with NPTL)

drow at gcc dot gnu dot org wrote:
> Just making sure I understand - catch (...) { foo(); throw; } will no
> longer call foo during forced unwinding, only destructors and explicit
> forced unwinding catches will be called?

Yes.  I should clarify that I'm just implementing all the different 
options, in hopes that helps to move the discussion along.

> [What does this imply for throw()?]

throw() will always block unwinding.  For that case "sticky" 
cancellation works better.  But I don't think that's actually an issue 
for iostreams, is it?

Jason


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[drow at gcc dot gnu dot org]

------- Comment #12 from drow at gcc dot gnu dot org  2006-08-01 13:02 -------
Subject: Re:  C++ (throw() and catch(...) {/*  fall through */ } ) and pthread
cancellation are incompatible (at least with NPTL)

On Tue, Aug 01, 2006 at 07:10:53AM -0000, jason at redhat dot com wrote:
> > [What does this imply for throw()?]
> 
> throw() will always block unwinding.  For that case "sticky" 
> cancellation works better.  But I don't think that's actually an issue 
> for iostreams, is it?

Right, I don't think so.


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at gcc dot gnu dot org]

------- Comment #13 from jason at gcc dot gnu dot org  2006-08-01 21:08 -------
Created an attachment (id=11988)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11988&action=view)
NPTL patch for sticky cancellation

Revised, tested patch with testcase.

So, there are 3 patches here, which are fairly independent of each other:

1) catch (abi::__forced_unwind &) -- this patch seems uncontroversial and I
think should go in very soon.
2) prevent catch (...) from catching forced unwind -- this change is highly
controversial.  The last time I brought up this topic I tried to convince C++
folks to subscribe to this perspective and failed.
3) "sticky cancel" (if cancellation exception is discarded, raise a new one at
the next cancellation point) -- Ulrich was strongly opposed to discarding the
cancellation exception in the past, but might be more open now that I have an
implementation.

As previously mentioned, #3 is the only way to deal with cancellation within
throw().  Cancellation will ignore other exception specifications.

#2 or #1 are enough to deal with the catch (...) problem.  #3 alone is not; it
can lead to an infinite loop of catch and discard in an outer loop that tries
to recover from exceptions.

#1 seems like a good thing regardless of #2 or #3.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #11979|0                           |1
        is obsolete|                            |


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[hhinnant at apple dot com]

------- Comment #14 from hhinnant at apple dot com  2006-11-01 23:33 -------
So swallowing a cancel-exception (in C++) is sometimes the right thing to do.

Imagine a thread pool executing a queue of tasks.  These tasks can well have
handles so that clients can wait/join with results in the future.  Such results
could be normal or exceptional.  If you've got a hung task in a thread pool,
maybe you want to cancel it.  That means the task should end, but once the OS
thread dumps the task, records the exception that ended it (cancellation), the
thread should be free to get the next task out of the queue and execute it.


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at redhat dot com]

------- Comment #15 from jason at redhat dot com  2007-04-13 20:13 -------
Subject: Re:  C++ (throw() and catch(...) {/*  fall through
 */ } ) and pthread cancellation are incompatible (at least with NPTL)

Howard's example seems to me like an argument for not necessarily using 
thread cancellation to abort a task, but not for discarding the cancel 
request entirely.  A cancellation request is asking for a thread to go 
away; if you want to send a different message use a different mechanism.

Jason


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[hhinnant at apple dot com]

------- Comment #16 from hhinnant at apple dot com  2007-04-15 16:13 -------
(In reply to comment #15)

This makes clean up / rethrow during cancellation awkward.  Code would have to
check for two (or more) different kinds of cancellation:  Am I executing in an
OS thread, or in a thread pool?


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at redhat dot com]

------- Comment #17 from jason at redhat dot com  2007-04-15 19:01 -------
Subject: Re:  C++ (throw() and catch(...) {/*  fall through
 */ } ) and pthread cancellation are incompatible (at least with NPTL)

hhinnant at apple dot com wrote:
> This makes clean up / rethrow during cancellation awkward.  Code would have to
> check for two (or more) different kinds of cancellation:  Am I executing in an
> OS thread, or in a thread pool?

Well, yes.  The mechanism for pthread_cancel won't necessarily work with 
other forms of cancellation.

Doing clean up in a catch(...) block has always been inelegant, a 
destructor will be more reliable.  I don't understand why we aren't 
adding finally in this round of standardization...


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[jason at gcc dot gnu dot org]

------- Comment #19 from jason at gcc dot gnu dot org  2010-07-16 19:21 -------
Created an attachment (id=21227)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21227&action=view)
final __forced_unwind patch and fixes applied in 2007, for historical reference


-- 


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

[Bug other/28145] C++ (throw() and catch(...) {/* fall through */ } ) and pthread cancellation are incompatible (at least with NPTL)

[nightstrike at gmail dot com]

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

nightstrike <nightstrike at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nightstrike at gmail dot
                   |                            |com

--- Comment #20 from nightstrike <nightstrike at gmail dot com> 2012-06-22 02:44:36 UTC ---
Give this:
http://thread.gmane.org/gmane.comp.gcc.help/41456

Will further work happen on this PR, Jason?