Not sure if the test failure is because of a timeout or a race that only becomes visible when run in valgrind.
Example: https://travis-ci.org/github/bitcoin/bitcoin/jobs/666899059#L6964
Not sure if the test failure is because of a timeout or a race that only becomes visible when run in valgrind.
Example: https://travis-ci.org/github/bitcoin/bitcoin/jobs/666899059#L6964
Nice catch!
From the Valgrind documentation FWIW:
The main thing to point out with respect to threaded programs is that your program will use the native threading library, but Valgrind serialises execution so that only one (kernel) thread is running at a time. This approach avoids the horrible implementation problems of implementing a truly multithreaded version of Valgrind, but it does mean that threaded apps never use more than one CPU simultaneously, even if you have a multiprocessor or multicore machine.
Valgrind doesn’t schedule the threads itself. It merely ensures that only one thread runs at once, using a simple locking scheme. The actual thread scheduling remains under control of the OS kernel. What this does mean, though, is that your program will see very different scheduling when run on Valgrind than it does when running normally. This is both because Valgrind is serialising the threads, and because the code runs so much slower than normal.
This difference in scheduling may cause your program to behave differently, if you have some kind of concurrency, critical race, locking, or similar, bugs. In that case you might consider using the tools Helgrind and/or DRD to track them down.