Re: helgrind (valgrind plugin) errors coming from nsdispatch(3)
On Monday, March 25, 2013 12:13:39 am Yuri wrote: 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? Hmm, try locks don't block, so if the only use of the mutex is try locks and the caller unwinds and releases the rwlock if the mutex try lock fails, no deadlock is possible. The WITNESS checker in the kernel ignores try locks when checking for lock order reversals for this reason. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
helgrind (valgrind plugin) errors coming from nsdispatch(3)
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) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
