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 (®istered) < 10000)
> {
> [...]
> atomic_fetch_add (®istered, 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