C++

Forum

 
 
helgrind reports lock ordering violation in the same thread.

Aug 4, 2021 at 12:21pm
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;
}
Edit & run on cpp.sh


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 Aug 4, 2021 at 12:22pm
Aug 4, 2021 at 12:38pm
helios (17523)
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.
Aug 18, 2021 at 4:18pm
hebrerillo (74)
OK I understand helios.

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