This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] Fix for bz14333 -- race between atexit() and exit()
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, Andreas Schwab <schwab at suse dot de>, Joseph Myers <joseph at codesourcery dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, Ricky Zhou <rickyz at google dot com>
- Date: Mon, 18 Sep 2017 16:03:46 -0700
- Subject: Re: [patch] Fix for bz14333 -- race between atexit() and exit()
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobNCZqgvcLJhuJt5eSWseuTfHJ9oVsG9TpPvytyfzF56mg@mail.gmail.com> <alpine.DEB.2.20.1707111221040.845@digraph.polyomino.org.uk> <CALoOobMw+FNimtKqhO4cyayp8HGeGWO55veqKCD=fNoknreXkA@mail.gmail.com> <alpine.DEB.2.20.1707111900580.9395@digraph.polyomino.org.uk> <CALoOobOgwZx2K-FWFi5zmqjk4vfxB4B2+Bv6koou7Ks9WCT4Yw@mail.gmail.com> <mvmwp7d7i29.fsf@suse.de> <CALoOobMnZ=dE52uWT-PXSb+Sz8SRbjG7FKCmuG+kZ47db76PUg@mail.gmail.com> <1500467179.27895.55.camel@redhat.com> <CALoOobPx5KHn7rGQKTy3UnEq_YnzXnGKrKCLmJHPd5bkipb79g@mail.gmail.com> <1500926864.30433.42.camel@redhat.com> <CALoOobO1sCK2jMJ69_r-m47PshpM3OnReWkAp6QA=vr6OycrJw@mail.gmail.com> <CALoOobPuWkBOjqMnb9OWf1-3G4=vXqL_Z0LTs7HWACn=Ew+mng@mail.gmail.com> <abd5aba0-4ffe-4794-f390-d57b1522b937@redhat.com> <CALoOobP4KGou=4OL7hVEDOTPesUyNnZE4CoaRhJCCU=RBGPyQQ@mail.gmail.com> <d4b7473f-92eb-db93-7b74-edc4805acffd@redhat.com>
On Mon, Sep 18, 2017 at 2:15 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> - uint64_t check = __new_exitfn_called;
>> + /* We don't want to run this cleanup more than once. */
>
> We have just changed the way locking works, and the above comment
> worries me, particularly for test coverage.
>
> Under what conditions can this function be called more than once?
Presumably the applicaton itself may call __cxa_finalize(NULL) from
multiple threads.
> Could we amend the comment here to be more descriptive then?
Sure.
> Is it a bug that the thread calling dlclose may be the only thread
> running this particular function while the other thread is running
> to exit?
>
> T1-> dlclose
> T1-> library destructors call __cxa_finalize
> T1-> picks function foo off the list, marks flavor ef_free
> T1-> unlocks list, starts executing foo.
> T2-> exit
> T2-> starts executing all destructors, skips foo marked ef_free
> T2-> proceeds to terminate the process
>
> Is T1's call to foo incomplete?
Yes. But an application that calls exit in parallel with running
threads always has the risk that any of its functions will
"evaporate" mid-sentence.
Also, AFAICT this patch does not change the behavior here: the exact
same incomplete call to foo can happen with current code.
Thanks,
--
Paul Pluzhnikov