This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]