helgrind reports lock ordering violation in the same thread.

hebrerillo (74)
Hello everyone!

Valgrind tool Helgrind is reporting a violation in the lock acquisition order... in the same thread.

In the example below there is only one thread (the main thread).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 

#include <mutex>

int main(void)
{
    std::mutex mutex1, mutex2;
    
    mutex1.lock();
    mutex2.lock();
    mutex2.unlock();
    mutex1.unlock();
    
    mutex2.lock();
    mutex1.lock();
    mutex1.unlock();
    mutex2.unlock();
    
    return 1;
}


This is the output after running the previous code under Helgrind:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 

==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.

Thank you very much!
Last edited on
helios (17574)
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.
hebrerillo (74)
OK I understand helios.

Thank you very much for your answer!
Topic archived. No new replies allowed.