This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Fix the race between atexit() and exit()
- From: Anoop <acv at linux dot vnet dot ibm dot com>
- To: "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: libc-help <libc-help at sourceware dot org>, suzuki at in dot ibm dot com
- Date: Wed, 04 Jun 2008 18:43:15 +0530
- Subject: Re: [PATCH] Fix the race between atexit() and exit()
- References: <firstname.lastname@example.org> <email@example.com>
Carlos O'Donell wrote:
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().
I agree, but this is a race between exit() and atexit() and not between
simultaneous exit() calls or simultaneous atexit() calls.
same as what the man page says -
The atexit() function shall register the function pointed to by func, to be
called without arguments at normal program termination. At normal program
termination, all functions registered by the atexit() function shall be called,
in the reverse order of their registration, except that a function is called
after any previously registered functions that had already been called at the
time it was registered
Though it doesnt say it is thread safe, atexit() is not listed in the
thread-unsafe functions listed in sextion 2.9.1 -
where it says - All functions defined by this volume of IEEE Std 1003.1-2001
shall be thread-safe, except that the following functions need not be
The bug arises even if there are only 2 threads where one calls exit() and the
other calls atexit() simultaneously. This could be hard to hit though.
So I think its not a question about the thread-safe attribute of the functions.
- Same comment as above -
2. Provide the test case.
#define REGISTER_ATEXITFUNC(x) void *register_atexit_func##x(void *t) \
while(thread_start == 0); \
*(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
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?
Yes the tests were run. No regressions could be found.