[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140805194117.GI1674@brightrain.aerifal.cx>
Date: Tue, 5 Aug 2014 15:41:17 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: PATCH: don't call cleanup handlers after a regular return
from the thread start function
On Tue, Aug 05, 2014 at 09:06:16PM +0200, Jens Gustedt wrote:
> Hello,
>
> Am Dienstag, den 05.08.2014, 13:09 -0400 schrieb Rich Felker:
> > > Linux manpages are more explicit and state:
> > >
> > > Clean-up handlers are not called if the thread terminates by
> > > performing a return from the thread start function.
> > >
> > > This patch aligns musl to that behavior.
> >
> > Could you clarify why this patch is necessary? I think such a return
> > is explicitly UB.
> >
> > "The effect of the use of return, break, continue, and goto to
> > prematurely leave a code block described by a pair of
> > pthread_cleanup_push() and pthread_cleanup_pop() functions calls is
> > undefined."
>
> yes
>
> The linux man page (glibc I suppose) has no such mention, only
> disallows longjmp and the phrase I cited above. I think this
> establishes an extension for POSIX on Linux systems.
I think what's going on here is that glibc implements cancellation
cleanup as unwinding, so whatever happens to be the behavior that
results from unwinding is what you get. However, I would think that
would cause the cleanup handlers to get run when returning from the
start function, rather than not running, since it's actually the
compiler that calls them, and the compiler has no way of knowing the
start function is special.
musl explicitly does not use unwinding for cancellation, and does not
attempt to provide related glibc semantics which are all in the realm
of UB per POSIX.
> But I have another reason for wanting that, future compatibility with
> C threads. Programs that are written for C threads will not be aware
> of such interdictions. Concretely in our case of my C thread v3 patch
> a user can longjmp from a once-init-handler (written by her or him)
> through pthread_once (in libc, for musl with pthread_cleanup_push) to
> the thread start function (again user code) and then return from
> there. (All of this seems to be allowed by POSIX)
Such a longjmp is UB unless it's explicitly permitted by the standard
-- same as longjmp out of qsort. There's no guarantee to a function
called as a callback from the standard library that the calling
function does not have internal state which would be left in an
inconsistent state by longjmp'ing out.
If call_once is explicitly required to support longjmp, then a
separate implementation of call_once is needed for C11 without
cancellation support. However I doubt this usage is supported, since
the state of the once_flag would have to be specified for such
interrupted calls, and I see no such specification.
> I consider to not execute the cleanup handlers a little bit more
> friendly than executing them.
musl does not do either. It's simply UB. At the point where you're
claiming the cleanup handler is executed, the pointer being
dereferenced is to an object whose lifetime has ended, so it's not
even making a call to the cleanup handler but simply invoking UB.
> Another possibility would be to split the behavior
>
> - abort for pthreads (this is nicer than executing the handlers or
> than silently ignore them)
>
> - ignore for C threads
There's no way it can happen for C threads unless they're actually
using pthread_cleanup_push, and the relevenat code that might be
returning is aware of POSIX and the reules for use of
pthread_cleanup_push.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
