Open kilobyte opened 5 years ago
This test can only be run on pmem. There is a bug in our test framework that we do not skip this on non-pmem. This is probably the issue.
cmake is invoked with -DTESTS_USE_FORCED_PMEM=1
— that should be enough, right?
Overnight stats: Pinnacle Ridge 3 ✗ 149 ✓, Skylake 17 ✗ 108 ✓ (the cluster of "semi-reliable" fails at the start was a fluke). The Skylake is much faster in single-threaded tests (and helgrind traces multiple guest threads in a single host thread).
It looks like false-positive. Thread 3 creates a new node while thread 4 changing the value of this node. But thread 4 acquire accessor to the node under the bucket lock. So it could happen only when the thread 3 creates the new node and releases the bucket lock.
It seems to work after: https://github.com/pmem/libpmemobj-cpp/pull/476 so I'll close it for now.
This seems to be reproducing more often now. I think we should think about some annotations for helgrind maybe?
Here's one more log: log_filt.txt
Let's disable it for now: https://github.com/pmem/libpmemobj-cpp/pull/625
After the relase we should look into our test cases and possibly add this test under drd instead of helgrind (also check if all concurrent tests are run under dd/helgrind)
Debian unstable: gcc-9, valgrind 3.15
Full log from two official buildds: x86-ubc-01, x86-csail-02.
On my home box (a 64-thread Pinnacle Ridge) I can't seem to reproduce despite multiple runs with exact same toolchain versions; on work desktop (8-thread Skylake) it semi-reliably fails in either concurrent_hash_map_insert_lookup_0_helgrind or concurrent_hash_map_rehash_0_helgrind). I'll leave it in a loop overnight.