Date: Sun, 24 Mar 2013 21:13:39 -0700 From: Yuri <yuri@rawbw.com> To: FreeBSD Hackers <hackers@freebsd.org> Subject: helgrind (valgrind plugin) errors coming from nsdispatch(3) Message-ID: <514FCEF3.8070902@rawbw.com>
next in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?514FCEF3.8070902>