I did this

We install the test suite so that we can run it on target as part of integration testing. Occasionally, one of the tests will timeout. For an example of this, see https://autobuilder.yocto.io/pub/non-release/20240409-14/testresults/qemux86-64-ptest/curl.log.

This shows test 340 fails after waiting two minutes for a response from the server. I initially blamed a heavily loaded host machine (as the tests are running inside a qemu-system) but the test execution started at 12:51, test 340 started at 12:52, and times out two minutes later at 12:54. This suggests that the other tests are all running quickly and the problem is not system load.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=15268 is our tracker bug for this issue, it can be seen that there's no hugely obvious pattern (to me, at least) to what tests fail. We also pass !flaky !timing-dependent to runtests.pl to filter out tests marked as such.

My hunch is that there's a subtle race in the test harness, which is only visible when running the tests frequently.

I expected the following

No response

curl/libcurl version

curl 8.7.1

operating system

OpenEmbedded