This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] pthread_once hangs when init routine throws an exception [BZ #18435]
- From: Martin Sebor <msebor at gmail dot com>
- To: Szabolcs Nagy <nsz at port70 dot net>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Martin Sebor <msebor at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Date: Wed, 08 Jul 2015 16:52:31 -0600
- Subject: Re: [PATCH] pthread_once hangs when init routine throws an exception [BZ #18435]
- Authentication-results: sourceware.org; auth=none
- References: <556B7F10 dot 40209 at redhat dot com> <559D4CD6 dot 5070607 at redhat dot com> <559D95F7 dot 902 at gmail dot com> <20150708221339 dot GN32532 at port70 dot net>
On 07/08/2015 04:13 PM, Szabolcs Nagy wrote:
* Martin Sebor <msebor@gmail.com> [2015-07-08 15:28:23 -0600]:
This patch has serious problems which cause regressions on at
least aarch64 and possibly other arches.
I finally got an Aarch64 box, managed to reproduce one of the two
reported test regressions (the one in tst-join5; the other test
passes for me) and have been debugging it in between other tasks.
we know the root cause already (you were somehow left
off from the cc at some point).
here is my analysis and carlos' reply:
http://sourceware.org/ml/libc-alpha/2015-07/msg00260.html
Ah, thank you! I've been busy with another project and haven't
had a chance to read the list. Let me digest it and follow up
on the thread. (A couple of comments are below.)
I'm not sure I understand what you mean here. The patch doesn't
introduce any assumptions that didn't exist before. Callers of
the cancellation functions don't depend on -fasynchronous-unwind-
tables: only the functions themselves do (when __EXCEPTIONS is
defined), and they are being compiled that way.
the new requirement is to compile pthread_once's
callback argument with async unwind info.
That's only required in C++ code that throws exceptions from
the once function. C callers are not affected (and in my
tests on aarch64 and ppc64le, they're compiled with neither
-fexceptions or -fasynchronous-unwind-tables and succeed).
This includes tst-once3 which you reported as failing so
there must be something more subtle going on.
the problem is that -fexceptions is not 'async unwind safe'
the cleanup handler is only guaranteed to run if the unwind
goes through extern functions (that may throw).
there is a proposed new cancellation design that gets rid
of async cancel + inline asm syscalls + cleanup handlers,
with that your patch would be safe, but without it, it isnt.
(that change is scheduled for 2.23)
I'm fine deferring the patch until 2.23, though I would like
to understand why we're seeing different results for some
of the tests.
Martin