[Valgrind-users] Helgrind lock order detection and memory re-use

[Nikolaus R. <Nik...@ra...>]

Hello,

I'm debugging a C++ program with Helgrind. The program is memcheck
clean. I am getting the following error (trimmed the stacktraces to the
relevant parts):

==1910679== Thread #4: lock order "0x4EB0948 before 0x18B920" violated
==1910679== 
==1910679== Observed (incorrect) order is: acquisition of lock at 0x18B920
==1910679==    by 0x1405CB: unique_lock (unique_lock.h:68)
==1910679==    by 0x1405CB: steamfs::do_lookup(unsigned long, char const*, fuse_entry_param*) (callbacks.cpp:410)
==1910679==    by 0x1491CA: create (callbacks.cpp:1429)
==1910679==    by 0x1491CA: operator() (callbacks.cpp:1447)
==1910679== 
==1910679==  followed by a later acquisition of lock at 0x4EB0948
==1910679==    by 0x14060D: unique_lock (unique_lock.h:68)
==1910679==    by 0x14060D: steamfs::do_lookup(unsigned long, char const*, fuse_entry_param*) (callbacks.cpp:418)
==1910679==    by 0x1491CA: create (callbacks.cpp:1429)
==1910679==    by 0x1491CA: operator() (callbacks.cpp:1447)
==1910679== 
==1910679== Required order was established by acquisition of lock at 0x4EB0948
==1910679==    by 0x141648: lock_guard (std_mutex.h:159)
==1910679==    by 0x141648: steamfs::do_readdir(fuse_req*, unsigned long, unsigned long, long, fuse_file_info const*, int) (callbacks.cpp:600)
==1910679==    by 0x14240F: readdirplus (callbacks.cpp:1384)
==1910679==    by 0x14240F: operator() (callbacks.cpp:1389)
==1910679== 
==1910679==  followed by a later acquisition of lock at 0x18B920
==1910679==    by 0x1405CB: unique_lock (unique_lock.h:68)
==1910679==    by 0x1405CB: steamfs::do_lookup(unsigned long, char const*, fuse_entry_param*) (callbacks.cpp:410)
==1910679==    by 0x141839: steamfs::do_readdir(fuse_req*, unsigned long, unsigned long, long, fuse_file_info const*, int) (callbacks.cpp:677)
==1910679==    by 0x14240F: readdirplus (callbacks.cpp:1384)
==1910679==    by 0x14240F: operator() (callbacks.cpp:1389)


The problem is that the code that accesses the second lock (0x4EB0948)
is not accessing the same variable. Now, it could of course be that
there is a bug somewhere that results in both variables pointing to the
same address, but it is much more likely that this is coincidence (since
both variables are part of structures that are dynamically allocated and
freed).

Is it possible that Helgrind is not recognizing that these are two
*different* locks with different lifetimes that just happen to be
allocated at the same address?


Best,
-Nikolaus


-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«