This is the mail archive of the 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()

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. says
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.

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.
- Same comment as above -

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.

- Anoop

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