Failure in stdlib/tst-arc4random-thread testing glibc 2.41 for release.

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 15/01/25 18:50, Florian Weimer wrote:
>> * Carlos O'Donell:
>> 
>>> Adhemerval,
>>>
>>> In testing glibc 2.41 for release I had this fail in a *very* surprising way:
>>> https://sourceware.org/glibc/wiki/Testing/Tests/stdlib/tst-arc4random-thread
>>>
>>> System is a local Lenovo P16v laptop under testing load:
>>>
>>> info: outer_threads=2 inner_threads=4
>>> info: arc4random: minimum of 163840 blob results expected
>>> info: arc4random: 163894 blob results observed
>>> error: arc4random: duplicate blob: "\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000" (16 bytes)
>>>   first source: thread -1, index 0
>>>   second source: thread -1, index 1
>>> info: arc4random_buf: minimum of 163840 blob results expected
>>> info: arc4random_buf: 163840 blob results observed
>>> info: arc4random_uniform: minimum of 163840 blob results expected
>>> info: arc4random_uniform: 163840 blob results observed
>>> error: 1 test failures
>> 
>> I can reproduce it on kernel 6.12.8 after a while running the test in a
>> loop, and multiple such loops in parallel (probably just to generate
>> load).  Thread -1 means that it happens after fork.  I see duplicates
>> not just with zeros.
>> 
>> First step would be to check if all the threads after fork receive
>> distinct per-thread states.  If not, there's probably a glitch in our
>> state allocation code.  Or maybe the state recovery from reclaim_stacks
>> produces duplicates
>
> Hm I will take a look. 

I think I found it: the len updates are not synchronized with fork, and
neither is the transfer from the states array to a thread and back.
After adding barriers, the states array may still contain null pointers,
so we should check for that and skip over them.

Thanks,
Florian