stdlib: Fix data race in __run_exit_handlers

Vitaly Buka vitalybuka@google.com
Tue Nov 18 06:47:03 GMT 2025


registered is incremented more than 10k, because it's
continuously decremented in atexit_cb.

This is a test to reproduce datarace, very flaky. I couldn't figure out a
better one.
I assume if you can undo the patch and reasonably consistently reproduce
the issue, then it's fine.

Another consideration is if maintaining such tests is worth the effort? But
this is a decision to make for glibc maintainers.

On Mon, Nov 17, 2025 at 11:55 AM Samuel Thibault <samuel.thibault@gnu.org>
wrote:

> Hello,
>
> In stdlib/test-cxa_atexit-race2, we have:
>
> static atomic_int todo = 100000;
>
> thread_func (void *arg)
> {
>   void *cb_arg = NULL;
>   while (atomic_load (&todo) > 0)
>     {
>       if (atomic_load (&registered) < 10000)
>         {
>           [...]
>           atomic_fetch_add (&registered, n);
>           atomic_fetch_sub (&todo, n);
>         }
>     }
>   return NULL;
> }
>
> I do not see the point of keeping the thread_func looping for nothing
> after doing its work? (registering 10000 times) Should todo actually be
> initialized to 10000 ?
>
> Samuel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251117/ff61d89f/attachment.htm>


More information about the Libc-alpha mailing list