Hi! 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 alloc'd ==2160== at 0x4C29418: operator new(unsigned long) (vg_replace_malloc.c:333) ... 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! Regards JK ------------------------------------------------------------------------------ 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! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
