Helgrind never shows how the lock order was established

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Helgrind never shows how the lock order was established

Jürgen Kadidlo

  I'm using valgrind 3.11.0 with helgrind to check for data races and
inconsistent lock orderings. The problem is, that helgrind reports lock
order violations but never shows how the required order was established.
I've expected output similar to that in the documentation at
http://valgrind.org/docs/manual/hg-manual.html but I've never actually
seen it for my code. All I get is:

==2160== Thread #15: lock order "0x95B5EC8 before 0x953DDD8" violated

==2160== Observed (incorrect) order is: acquisition of lock at 0x953DDD8
==2160==    at 0x4C2BC87: mutex_lock_WRK (hg_intercepts.c:901)
==2160==    by 0x4C2FADB: pthread_mutex_lock (hg_intercepts.c:917)
==2160==    by 0x68AD9B5: lock (mutex.h:26)

followed by a later acquisition of lock at 0x95B5EC8
==2160==    at 0x4C2BC87: mutex_lock_WRK (hg_intercepts.c:901)
==2160==    by 0x4C2FADB: pthread_mutex_lock (hg_intercepts.c:917)
==2160==    by 0x68BCD05: lock (mutex.h:26)

==2160==  Lock at 0x95B5EC8 was first observed
==2160==    at 0x4C2FA43: pthread_mutex_init (hg_intercepts.c:779)
==2160==  Address 0x95b5ec8 is 1,176 bytes inside a block of size 2,216
==2160==    at 0x4C29418: operator new(unsigned long)

Am I doing something wrong? Is this a known bug?

Because of the complexity of the code, it can be really hard to manually
determine a different lock order, therefore the missing "Required order
was established" information would be very much appreciated!



Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
Valgrind-users mailing list
[hidden email]