From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 25 04:42:21 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A389E24 for ; Mon, 25 Mar 2013 04:42:21 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 71350954 for ; Mon, 25 Mar 2013 04:42:21 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r2P4Ddpe033791 for ; Sun, 24 Mar 2013 21:13:39 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <514FCEF3.8070902@rawbw.com> Date: Sun, 24 Mar 2013 21:13:39 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130226 Thunderbird/17.0.3 MIME-Version: 1.0 To: FreeBSD Hackers Subject: helgrind (valgrind plugin) errors coming from nsdispatch(3) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 04:42:21 -0000 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)