[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