Re: [PATCH] Fix the race between atexit() and exit()

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Tue, Jun 3, 2008 at 7:49 PM, Carlos O'Donell <carlos@systemhalted.org> wrote:
> On Tue, Jun 3, 2008 at 12:23 PM, Anoop <acv@linux.vnet.ibm.com> wrote:
>>
>> Quoting Carlos O'Donell <carlos@systemhalted.org>:
>>
>>> 1. Describe in detail the conditions of the race and your proposed fix.
>>
>> current exit() code
>> ==================
>> while (__exit_funcs != NULL) <==== not atomic, also what if a new handler is
>> registered right after this
>
> The standard does not say that exit() is thread-safe or async-signal
> safe. I recommend using pthread_exit().
>
>>> 2. Provide the test case.
>> #define REGISTER_ATEXITFUNC(x) void *register_atexit_func##x(void *t)   \
>>        {                                               \
>>                while(thread_start == 0);               \
>>                if(atexit(atexit_func##x))                      \
>>            write(2,"F\n",2); \
>>        else \
>>                    *(data - 10  + x) = x -10; \
>>        }
>
> The standard does not say that atexit() is thread-safe or async-signal
> safe. I recommend using pthread_cleanup_* functions.
>
>>> 3. Run the testsuite for your target to show there were no
>>> regressions. Mention the target.
>>
>> The test was run for about 10 hrs in loop in an x86_64 SMP target without
>> failures.
>
> When you make a change to a source base, like the C library, you need
> to run the C library testsuite *before* and *after* your patch to
> verify that none of the existing functionality was altered by your
> changes. Have you run the C library test suite? e.g. make -k check?
>
>>> 4. When quoting POSIX  please provide references.
>>
>> POSIX Ref: =>   man 3p atexit
>
> The man page is not a good reference, it may not actually match the
> standard. I recommend http://www.opengroup.org/onlinepubs/009695399/.
>
> In general these comments apply only to single threaded programs that
> are not using signals or threads.
>
> In the case of signals you need to verify that the functions you are
> calling are reentrant or async-signal safe.
>
> Then you need to verify if the standard says they are thread safe.
>
> Please remember that reentrant and thread safety are two separate issues.
>
> For the record I've CC'd libc-alpha, but we should continue this
> conversation on libc-help.
>
> Cheers,
> Carlos.
>

For the record.

Note: One can't email libc-alpha and libc-help at the same time.

Cheers,
Carlos.