[pulseaudio-discuss] Test failure on musl libc and slower builders (thread-test timeout)

[Tanu Kaskinen]

On Mon, 2017-01-16 at 16:37 -0600, A. Wilcox wrote:
> Hello,
> 
> While packaging PulseAudio for our distribution, I noticed the test
> suite failing in two different ways; both of these failures are in
> thread-test.
> 
> The first failure is related to pulseaudio's usage of rand().
> According to POSIX[1], calls to rand() without first calling srand()
> result in proceeding as if you had called srand(1) first.  On the musl
> libc, seeding with 1 gives 0 as the first number (which is valid;
> numbers can be within 0 and RAND_MAX).  Unfortunately, that means the
> test instantly deadlocks due to seeing 0 as the random number.
> 
> I would personally suggest that the test should spin if rand() returns
> 0, since that is perfectly acceptable behaviour and you really can't
> control expectations for what a random number generator will provide you.

Thanks for reporting the bug! I submitted a patch that adds 1 to the
rand() return value, that seemed slightly simpler than spinning.

> The second failure is that after I resolved the above issue (even just
> calling srand with '2' to avoid spinning too long), our PowerPC
> builder - a dual 1.8GHz 970fx - timed out.  Running it outside of
> 'make check' allows me to see it completes somewhere between 84 and 89
> iterations before the timeout hits.

What's the current timeout? 5 seconds? The test case doesn't seem to
specify it, and I don't remember what the default timeout is. I think
we should increase the timeout if it's too low even for reasonably
powerful processors.

-- 
Tanu

https://www.patreon.com/tanuk