helgrind (valgrind plugin) errors coming from nsdispatch(3)

Yuri yuri at rawbw.com
Mon Mar 25 04:42:21 UTC 2013


While running helgrind on my program, I observed several errors that 
stem from the nsdispatch calls, see helgrind log below.
"lock order" error in helgrind is generated when some data is protected 
by two mutexes, and they were locked in different order on different 
occasions.
I think, mutexes in question are nss_lock and conf_lock in 
lib/libc/net/nsdispatch.c

It seems like authors of helgrind took an approach that such situation 
is error prone in general, thus they point it out.

So what would be the prevalent judgement here, is this something worth 
fixing in libc, or such errors should be ignored?

9.1-STABLE amd64
valgrind-3.8.0_1,1

Yuri



---helgrind log---
==6736== Thread #1: lock order "0x282B150 before 0x282B190" violated
==6736==
==6736== Observed (incorrect) order is: acquisition of lock at 0x282B190
==6736==    at 0x155AA4F: pthread_mutex_trylock (hg_intercepts.c:550)
==6736==    by 0x25B87F8: nsdispatch (in /lib/libc.so.7)
==6736==    by 0x25A3C50: getpwuid_r (in /lib/libc.so.7)
==6736==    by 0x3153EAA: ???
==6736==    by 0x3152B5D: ???
==6736==    by 0x3074F3C: ???
==6736==    by 0x8225A6: myfunc2(bool) (my1.cpp:146)
==6736==    by 0x5FC14A: myfunc1(int, char**) (my2.cpp:39)
==6736==    by 0x5E5B61: main (main.cpp:326)
==6736==
==6736==  followed by a later acquisition of lock at 0x282B150
==6736==    at 0x155C27F: pthread_rwlock_wrlock_WRK (hg_intercepts.c:1479)
==6736==    by 0x25B8818: nsdispatch (in /lib/libc.so.7)
==6736==    by 0x25A3C50: getpwuid_r (in /lib/libc.so.7)
==6736==    by 0x3153EAA: ???
==6736==    by 0x3152B5D: ???
==6736==    by 0x3074F3C: ???
==6736==    by 0x8225A6: myfunc2(bool) (my1.cpp:146)
==6736==    by 0x5FC14A: myfunc1(int, char**) (my2.cpp:39)
==6736==    by 0x5E5B61: main (main.cpp:326)
==6736==
==6736== Required order was established by acquisition of lock at 0x282B150
==6736==    at 0x155C44F: pthread_rwlock_rdlock_WRK (hg_intercepts.c:1532)
==6736==    by 0x25B8126: nsdispatch (in /lib/libc.so.7)
==6736==    by 0x25A3C50: getpwuid_r (in /lib/libc.so.7)
==6736==    by 0x3153EAA: ???
==6736==    by 0x3152B5D: ???
==6736==    by 0x3074F3C: ???
==6736==    by 0x8225A6: myfunc2(bool) (my1.cpp:146)
==6736==    by 0x5FC14A: myfunc1(int, char**) (my2.cpp:39)
==6736==    by 0x5E5B61: main (main.cpp:326)
==6736==
==6736==  followed by a later acquisition of lock at 0x282B190
==6736==    at 0x155AA4F: pthread_mutex_trylock (hg_intercepts.c:550)
==6736==    by 0x25B87F8: nsdispatch (in /lib/libc.so.7)
==6736==    by 0x25A3C50: getpwuid_r (in /lib/libc.so.7)
==6736==    by 0x3153EAA: ???
==6736==    by 0x3152B5D: ???
==6736==    by 0x3074F3C: ???
==6736==    by 0x8225A6: myfunc2(bool) (my1.cpp:146)
==6736==    by 0x5FC14A: myfunc1(int, char**) (my2.cpp:39)
==6736==    by 0x5E5B61: main (main.cpp:326)



More information about the freebsd-hackers mailing list