[Bug nptl/18435] New: pthread_once hangs when init routine throws an exception

[Bug nptl/18435] New: pthread_once hangs when init routine throws an exception

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

            Bug ID: 18435
           Summary: pthread_once hangs when init routine throws an
                    exception
           Product: glibc
           Version: 2.21
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: msebor at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

As discussed in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146, pthread_once
on at least ARM and PowerPC (but not x86_64) doesn't interact well with C++
exceptions thrown from the init routine.  The following test case demonstrates
the problem: it hangs in pthread_once until it's interrupted by SIGALRM.  The
test case runs successfully to completion on x86_64.

$ cat /home/remote/msebor/tmp/once.cc && g++ -Wall -g -lpthread
/home/remote/msebor/tmp/once.cc && gdb -batch -q -ex "catch signal SIGALRM" -ex
r -ex bt ./a.out
#include <errno.h>
#include <pthread.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

static pthread_once_t once = PTHREAD_ONCE_INIT;
struct OnceException { };

static int niter;

static void init_routine (void) {
  if (niter < 2)
    throw OnceException ();
}

int main (void) {
  int result = 1;

  alarm (5);

  for (niter = 0; niter != 3; ++niter) {

    try {
      int rc = pthread_once (&once, init_routine);
      if (rc)
        fprintf (stderr, "pthread_once failed: %i (%s)\n",
                 rc, strerror (rc));

      if (niter < 2)
        fputs ("pthread_once unexpectedly returned without"
               " throwing an exception", stderr);
    }
    catch (OnceException) {
      if (1 < niter)
        fputs ("pthread_once unexpectedly threw", stderr);
      result = 0;
    }
    catch (...) {
      fputs ("pthread_once threw an unknown exception", stderr);
    }

    if (result)
      break;
  }

  return result;
}
Catchpoint 1 (signal SIGALRM)
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/power8/libthread_db.so.1".

Catchpoint 1 (signal SIGALRM), 0x00003fffb7f4f7bc in pthread_once () from
/lib64/power8/libpthread.so.0
#0  0x00003fffb7f4f7bc in pthread_once () from /lib64/power8/libpthread.so.0
#1  0x0000000010000c0c in main () at /home/remote/msebor/tmp/once.cc:25

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

--- Comment #1 from Martin Sebor <msebor at redhat dot com> ---
Created attachment 8326
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8326&action=edit
Proposed patch tested on powerpc64le and x86_64.

The attached patch fixes the problem by replacing the problematic
pthread_cleanup_push and pthread_cleanup_pop macros with a cleanup handler.

2015-05-19  Martin Sebor  <msebor@redhat.com>

        * nptl/pthread_once (CleanupInfo): New struct.
        (clear_once_control): Replace...
        (cleanup_maybe_clear_once_control): ...with this.
        (__pthread_once_slow): Replace calls to pthread_cleanup_push and
        pthread_cleanup_pop with a cleanup object of struct CleanupInfo .
        * nptl/tst-once5.cc: New test.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

Jonathan Wakely <jwakely.gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
I don't think this is valid usage of pthread_once; at least, it's not portable,
and I would be hesitant to add support for this usage to glibc since it may
encourage non-portable usage.

I opened the following issue on the POSIX tracker which was related a while
back, and it was resolved to clarify that use of longjmp to exit the
init_routine results in undefined behavior:

http://austingroupbugs.net/view.php?id=863

The possibility of using C++ exceptions to exit was overlooked/not covered,
since POSIX really has nothing to say about C++, but conversely there is no
requirement to support such usage.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

--- Comment #3 from Martin Sebor <msebor at redhat dot com> ---
Thanks for the reference to the POSIX issue.  I admit I was initially also
skeptical that this use case was intended to be supported by POSIX but became
convinced after reading the following quotes from the spec:

http://permalink.gmane.org/gmane.comp.lib.boost.devel/128855

It seems clear that POSIX not only intends to support such a use case (of
pthread_cleanup_push/pop) but even encourages exception-aware implementations
(referring to them as "the ideal solution").

With that in mind, though, I'm starting to think that a better solution than
the one proposed in my patch is actually to change pthread_cleanup_push/pop to
be usable with exceptions (i.e., in C code that calls into C++ code that
throws).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Wed, 20 May 2015, msebor at redhat dot com wrote:

> Thanks for the reference to the POSIX issue.  I admit I was initially also
> skeptical that this use case was intended to be supported by POSIX but became
> convinced after reading the following quotes from the spec:
> 
> http://permalink.gmane.org/gmane.comp.lib.boost.devel/128855
> 
> It seems clear that POSIX not only intends to support such a use case (of
> pthread_cleanup_push/pop) but even encourages exception-aware implementations
> (referring to them as "the ideal solution").

You should be skeptical that wording inherited more or less unchanged from 
the rationale in the 1995/6 edition of POSIX.1 is particularly relevant to 
what's ideal in 2015, especially given that the then-anticipated rework of 
POSIX into a language-independent specification with separate C language 
bindings never materialized.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

--- Comment #5 from Martin Sebor <msebor at redhat dot com> ---
A data point to add to comment #3: The comment above the pthread_once
declaration in sysdeps/nptl/pthread.h indicates that glibc anticipates that
programs might throw exceptions from the init routine.  The comment was added
when the __THROW decoration was removed from the function (in 2004). 
Unfortunately, no test case seems to have been added along with the change.

/* Guarantee that the initialization function INIT_ROUTINE will be called
   only once, even if pthread_once is executed several times with the
   same ONCE_CONTROL argument. ONCE_CONTROL must point to a static or
   extern variable initialized to PTHREAD_ONCE_INIT.

   The initialization functions might throw exception which is why
   this function is not marked with __THROW.  */
extern int pthread_once (pthread_once_t *__once_control,
                         void (*__init_routine) (void)) __nonnull ((1, 2));

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

--- Comment #6 from Martin Sebor <msebor at redhat dot com> ---
Created attachment 8329
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8329&action=edit
Alternate patch.

The attached patch solves the same problem by removing the re-definitions of
the pthread_cleanup_push and _pop macros from nptl/pthreadP.h.  Also tested on
powerpc64le and x86_64.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

--- Comment #7 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54 (commit)
      from  9081b7bcb11e74cd2d4363663ccd1bb641392719 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54

commit ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54
Author: Martin Sebor <msebor@redhat.com>
Date:   Wed Jul 1 14:05:27 2015 -0600

    The C++ 2011 std::call_once function is specified to allow
    the initialization routine to exit by throwing an exception.
    Such an execution, termed exceptional, requires call_once to
    propagate the exception to its caller.  A program may contain
    any number of exceptional executions but only one returning
    execution (which, if it exists, must be the last execution
    with the same once flag).

    On POSIX systems such as Linux, std::call_once is implemented
    in terms of pthread_once.  However, as discussed in libstdc++
    bug 66146 - "call_once not C++11-compliant on ppc64le," GLIBC's
    pthread_once hangs when the initialization function exits by
    throwing an exception on at least arm and ppc64 (though
    apparently not on x86_64).  This effectively prevents call_once
    from conforming to the C++ requirements since there doesn't
    appear to be a thread-safe way to work around this problem in
    libstdc++.

    This patch changes pthread_once to handle gracefully init
    functions that exit by throwing exceptions. It was successfully
    tested on ppc64, ppc64le, and x86_64.

            [BZ #18435]
            * nptl/Makefile: Add tst-once5.cc.
            * nptl/pthreadP.h (pthread_cleanup_push, pthread_cleanup_pop):
            Remove macro redefinitions.
            * nptl/tst-once5.cc: New test.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog         |    8 +++++
 NEWS              |   10 +++---
 nptl/Makefile     |    3 +-
 nptl/pthreadP.h   |    7 ----
 nptl/tst-once5.cc |   80 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 5 files changed, 95 insertions(+), 13 deletions(-)
 create mode 100644 nptl/tst-once5.cc

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

Martin Sebor <msebor at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
           Assignee|unassigned at sourceware dot org   |msebor at redhat dot com
   Target Milestone|---                         |2.22

--- Comment #8 from Martin Sebor <msebor at redhat dot com> ---
Fixed by the committed patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[msebor at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

Martin Sebor <msebor at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #9 from Martin Sebor <msebor at redhat dot com> ---
Reopening since the committed patch caused regressions on aarch64 and also
powerpc64 and powerpc64le.  See the discussion in the thread below for more:
https://sourceware.org/ml/libc-alpha/2015-07/msg00141.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

--- Comment #10 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  203c1a898dd2e281eae30f3c57ceb8d4a50b00f4 (commit)
      from  2193ce8746ec11b2325cc55aa8f338d5872492bf (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=203c1a898dd2e281eae30f3c57ceb8d4a50b00f4

commit 203c1a898dd2e281eae30f3c57ceb8d4a50b00f4
Author: Martin Sebor <msebor@gcc.gnu.org>
Date:   Thu Jul 9 19:25:38 2015 -0400

    The patch committed to fix bug #18435 caused regressions on aarch64
    and also powerpc64 and powerpc64le. See the discussion in the thread
    below for details. This change reverts the problematic bits leaving
    the added test in place and marking XFAIL in anticipation of fixing
    the bug in the near future.
    https://sourceware.org/ml/libc-alpha/2015-07/msg00141.html

        [BZ #18435]
        * nptl/pthreadP.h (pthread_cleanup_push, pthread_cleanup_pop):
        Revert commit ed225df3ad9cbac3c22ec3f0fbbed1f9c61d1c54.
        * nptl/Makefile (test-xfail-tst-once5): Define.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog       |    7 +++++++
 NEWS            |   12 ++++++------
 nptl/Makefile   |    4 ++++
 nptl/pthreadP.h |   11 +++++++++++
 4 files changed, 28 insertions(+), 6 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[jakub at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

Jakub Jelinek <jakub at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.34
         Resolution|---                         |FIXED
                 CC|                            |jakub at redhat dot com
             Status|NEW                         |RESOLVED

--- Comment #19 from Jakub Jelinek <jakub at redhat dot com> ---
commit f0419e6a10740a672b28e112c409ae24f5e890ab (HEAD -> master, origin/master,
origin/HEAD)
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Mar 4 15:15:33 2021 +0100

    [PATCH] pthread_once hangs when init routine throws an exception [BZ
#18435]

    This is another attempt at making pthread_once handle throwing exceptions
    from the init routine callback.  As the new testcases show, just switching
    to the cleanup attribute based cleanup does fix the tst-once5 test, but
    breaks the new tst-oncey3 test.  That is because when throwing exceptions,
    only the unwind info registered cleanups (i.e. C++ destructors or cleanup
    attribute), when cancelling threads and there has been unwind info from the
    cancellation point up to whatever needs cleanup both unwind info registered
    cleanups and THREAD_SETMEM (self, cleanup, ...) registered cleanups are
    invoked, but once we hit some frame with no unwind info, only the
    THREAD_SETMEM (self, cleanup, ...) registered cleanups are invoked.
    So, to stay fully backwards compatible (allow init routines without
    unwind info which encounter cancellation points) and handle exception
throwing
    we actually need to register the pthread_once cleanups in both unwind info
    and in the THREAD_SETMEM (self, cleanup, ...) way.
    If an exception is thrown, only the former will happen and we in that case
    need to also unregister the THREAD_SETMEM (self, cleanup, ...) registered
    handler, because otherwise after catching the exception the user code could
    call deeper into the stack some cancellation point, get cancelled and then
    a stale cleanup handler would clobber stack and probably crash.
    If a thread calling init routine is cancelled and unwind info ends before
    the pthread_once frame, it will be cleaned up through self->cleanup as
    before.  And if unwind info is present, unwind_stop first calls the
    self->cleanup registered handler for the frame, then it will call the
    unwind info registered handler but that will already see __do_it == 0
    and do nothing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/18435] pthread_once hangs when init routine throws an exception

[jakub at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18435

--- Comment #20 from Jakub Jelinek <jakub at redhat dot com> ---
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f0419e6a10740a672b28e112c409ae24f5e890ab

-- 
You are receiving this mail because:
You are on the CC list for the bug.