diff options
author | Jakub Jelinek <jakub@redhat.com> | 2021-03-04 15:15:33 +0100 |
---|---|---|
committer | Jakub Jelinek <jakub@redhat.com> | 2021-03-04 15:15:33 +0100 |
commit | f0419e6a10740a672b28e112c409ae24f5e890ab (patch) | |
tree | 48034df63bcf917ba4a4b59c6c9238798e67e233 /nptl/Makefile | |
parent | 82215c1e251cf9a4668608974784c412d09c7ccd (diff) | |
download | glibc-f0419e6a10740a672b28e112c409ae24f5e890ab.tar.gz glibc-f0419e6a10740a672b28e112c409ae24f5e890ab.tar.xz glibc-f0419e6a10740a672b28e112c409ae24f5e890ab.zip |
[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.
Diffstat (limited to 'nptl/Makefile')
-rw-r--r-- | nptl/Makefile | 4 |
1 files changed, 0 insertions, 4 deletions
diff --git a/nptl/Makefile b/nptl/Makefile index 5f85dd7854..33766eaf7a 100644 --- a/nptl/Makefile +++ b/nptl/Makefile @@ -386,10 +386,6 @@ xtests += tst-eintr1 test-srcs = tst-oddstacklimit -# Test expected to fail on most targets (except x86_64) due to bug -# 18435 - pthread_once hangs when init routine throws an exception. -test-xfail-tst-once5 = yes - gen-as-const-headers = unwindbuf.sym \ pthread-pi-defines.sym |