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

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Thu Jan 16 13:42:54 GMT 2025



On 16/01/25 10:31, Florian Weimer wrote:
> * 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.

Do you mean adding atomic_thread_fence_seq_cst() on 'len' updates? Yeah
it makes sense and it explains why this only happens intermittently. 


More information about the Libc-alpha mailing list