Open kloczek opened 1 year ago
Hi @kloczek,
Can you share some details of the environment you are running the test suite in? (OS release, architecture, libevent version)
For diagnostic steps, I would suggest running each test in turn to figure out which one is hanging, and attaching a gdb / lldb to the apparently spinning process (2429310) and determining where in the code the loop is occuring.
(Edited: for some reason the github issue page isn't displaying the ps
output, but cutting and pasting to text shows the process tree.)
Thanks, -Chris
Can you share some details of the environment you are running the test suite in? (OS release, architecture, libevent version)
Linux x86/64, my own distribution. libevent 2.1.12.
(Edited: for some reason the github issue page isn't displaying the ps output, but cutting and pasting to text shows the process tree.)
That what I've exactly copied 😋
Last process in that tree is valgrind -q --error-exitcode=1 --leak-check=full --trace-children=yes --trace-children-skip=/usr/*,/bin/* ./t/test_queue spin 128 1
Thanks!
On an x86/64 Linux system, the test ./t/test_queue spin 128 1
runs to completion when not running under valgrind, which implies that valgrind's memcheck is either slowing things down further than usual or otherwise interacting poorly with the queue code. The test did finish (albeit very slowly) without --leak-check=full
.
The best solution may be to opt these tests out of valgrind.
I'v been runnimt tthat test 4 or 5 hours .. on quite powerful 24 cores box with NVMe storage.
Can you confirm that the tests run without valgrind in your environment? (i.e., run ./t/test_queue spin 128 1
from the build directory or configure without valgrind)
one sec ..
Looks like without valgrind it it was possible ti buid and test fstrm in 40s
I found that test suite is stuck and cannot finish. Part of the
ps auxwf
outputI'm not sure what I can try to do to diagnose that issue.