==216607== Thread #1: lock order "0x1FFEFFFE00 before 0x1FFEFFFE30" violated
==216607==
==216607== Observed (incorrect) order is: acquisition of lock at 0x1FFEFFFE30
==216607== at 0x483FB68: mutex_lock_WRK (hg_intercepts.c:907)
==216607== by 0x4843A65: pthread_mutex_lock (hg_intercepts.c:923)
==216607== by 0x10B653: __gthread_mutex_lock(pthread_mutex_t*) (gthr-default.h:749)
==216607== by 0x10B6A7: std::mutex::lock() (std_mutex.h:100)
==216607== by 0x10B5EE: main (main.cpp:12)
==216607==
==216607== followed by a later acquisition of lock at 0x1FFEFFFE00
==216607== at 0x483FB68: mutex_lock_WRK (hg_intercepts.c:907)
==216607== by 0x4843A65: pthread_mutex_lock (hg_intercepts.c:923)
==216607== by 0x10B653: __gthread_mutex_lock(pthread_mutex_t*) (gthr-default.h:749)
==216607== by 0x10B6A7: std::mutex::lock() (std_mutex.h:100)
==216607== by 0x10B5FA: main (main.cpp:13)
==216607==
==216607== Required order was established by acquisition of lock at 0x1FFEFFFE00
==216607== at 0x483FB68: mutex_lock_WRK (hg_intercepts.c:907)
==216607== by 0x4843A65: pthread_mutex_lock (hg_intercepts.c:923)
==216607== by 0x10B653: __gthread_mutex_lock(pthread_mutex_t*) (gthr-default.h:749)
==216607== by 0x10B6A7: std::mutex::lock() (std_mutex.h:100)
==216607== by 0x10B5BE: main (main.cpp:7)
==216607==
==216607== followed by a later acquisition of lock at 0x1FFEFFFE30
==216607== at 0x483FB68: mutex_lock_WRK (hg_intercepts.c:907)
==216607== by 0x4843A65: pthread_mutex_lock (hg_intercepts.c:923)
==216607== by 0x10B653: __gthread_mutex_lock(pthread_mutex_t*) (gthr-default.h:749)
==216607== by 0x10B6A7: std::mutex::lock() (std_mutex.h:100)
==216607== by 0x10B5CA: main (main.cpp:8)
Helgrind reports a lock ordering violation even though the program has only one thread.
Does that make sense? Is there a way to tell Helgrind to only check lock ordering between different threads?
I know I can disable lock ordering consistency checking by using the option '--track-lockorders=no', but I want to keep that option because there might be lock ordering violation between two different threads.
Helgrind merely detects that the lock order is inconsistent, which is a potential source of bugs. It doesn't care that both lock sequences are in the same thread because it has no way to predict how the function may be used in a different context. For example, if you were to call the function from some other code and that code picks only one of those lock orders, that would result in a deadlock.