[patch] Fix for bz14333 -- race between atexit() and exit()
Paul Pluzhnikov
ppluzhnikov@google.com
Mon Sep 18 23:04:00 GMT 2017
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
More information about the Libc-alpha
mailing list