Re: commit 16adc58e73f3 (stdlib: Fix data race in __run_exit_handlers [BZ #27749])

[Vitaly Buka <vitalybuka@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

Not sure how this happened, but it was not on my patch
https://sourceware.org/pipermail/libc-alpha/2021-April/125470.html

On Sun, 12 Feb 2023 at 15:44, Rasmus Villemoes <rasmus.villemoes@prevas.dk>
wrote:

> I think the commit in $subject is broken. I was browsing through the
> atexit handling code and stumbled on something which is always a code
> smell, namely the pattern
>
>   if (whatever)
>     continue;
>
> at the end of a loop.
>
> And indeed, since we no longer jump back to the outer loop and refetch
> the list head, one can observe a change in behavior. This program:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> void h(void)
> {
>         printf("third: %s()\n", __func__);
> }
> void j(void)
> {
>         printf("second: %s()\n", __func__);
> }
>
> void g(void)
> {
>         printf("first: %s()\n", __func__);
>         atexit(h);
>         atexit(j);
> }
> void f(void) {
>         static int c;
>         printf("%s: %d\n", __func__, ++c);
> }
>
> int main(int argc, char *argv[])
> {
>         int i;
>
>         /*
>          * Stuff the "struct exit_function_list" with dummy callbacks;
>          * 30 may need to be adjusted depending on how many atexit()
>          * registrations libc itself does.
>          */
>         for (i = 0; i < 30; ++i)
>                 atexit(f);
>
>         /* Register one more, to fill the last slot in struct
> exit_function_list. */
>         atexit(g);
>
>         return 0;
> }
>
> used to print
>
> first: g()
> second: j()
> third: h()
> f: 1
> ...
> f: 30
>
> but now it instead prints
>
> first: g()
> third: h()
> f: 1
> ...
> f: 30
> second: j()
>
>
> Rasmus
>