From g3c7a531@dmr.ath.cx  Tue Jul 13 14:44:49 2004
Return-Path: <g3c7a531@dmr.ath.cx>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 038A416A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 13 Jul 2004 14:44:49 +0000 (GMT)
Received: from dmr.ath.cx (ppp150-162.lns2.mel2.internode.on.net [150.101.150.162])
	by mx1.FreeBSD.org (Postfix) with ESMTP id F18F543D41
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 13 Jul 2004 14:44:46 +0000 (GMT)
	(envelope-from g3c7a531@dmr.ath.cx)
Received: from dmr.ath.cx (localhost [127.0.0.1])
	by dmr.ath.cx (8.12.11/8.12.11) with ESMTP id i6DEiAaT000671
	(version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO)
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 14 Jul 2004 00:44:10 +1000 (EST)
Received: (from emikulic@localhost)
	by dmr.ath.cx (8.12.11/8.12.11/Submit) id i6DEi42E026542
	for FreeBSD-gnats-submit@freebsd.org; Wed, 14 Jul 2004 00:44:04 +1000 (EST)
Message-Id: <20040713144404.GA24997@dmr.ath.cx>
Date: Wed, 14 Jul 2004 00:44:04 +1000
From: Emil Mikulic <g3c7a531@dmr.ath.cx>
To: FreeBSD-gnats-submit@freebsd.org
Subject: valgrind stuck in umtx state before exit
X-Send-Pr-Version: 3.113

>Number:         68992
>Category:       kern
>Synopsis:       valgrind stuck in umtx state before exit
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jul 13 14:50:20 GMT 2004
>Closed-Date:    Wed Jul 14 09:26:02 GMT 2004
>Last-Modified:  Wed Jul 14 09:26:02 GMT 2004
>Originator:     
>Release:        FreeBSD 5.2-CURRENT i386
>Organization:
>Environment:
System: FreeBSD beastie.home 5.2-CURRENT FreeBSD 5.2-CURRENT #2: Tue Jul 13 23:10:20 EST 2004 root@beastie.home:/usr/obj/usr/src/sys/PANTSU i386

>Description:
I'm inclined to think this is a bug in the kernel rather than valgrind
because this wasn't happening with a kernel from a few weeks ago.

I'm running a 5-CURRENT world and kernel as of 13 July 2004 at 12:40
UTC.  valgrind hangs before exit, after printing leak information.  top
says it's stuck in the umtx state:

  PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU    CPU COMMAND
  516 emikulic  95    0   335M  7176K umtx     0:00  0.00%  0.00% valgrind

DDB's ps says:

  pid   proc     uarea   uid  ppid  pgrp  flag   stat  wmesg    wchan  cmd
  516 c18928ac d83f0000 1000   458   516 0004002 [SLPQ umtx 0xc17fa000][SLP] valgrind

I can't kill it with SIGTERM, SIGINT, or SIGQUIT, and I can't suspend
it.  It dies on SIGKILL though.

I get the same behaviour with both valgrind-327 and
valgrind-snapshot-337.

>How-To-Repeat:
	valgrind --tool=memcheck ls
>Fix:
>Release-Note:
>Audit-Trail:

From: Emil Mikulic <g3c7a531@dmr.ath.cx>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/68992: valgrind stuck in umtx state before exit
Date: Wed, 14 Jul 2004 17:04:13 +1000

 I've found three commits (through binary search with cvsup) after which
 the umtx hang happens:
 
 http://lists.freebsd.org/pipermail/cvs-src/2004-July/026488.html
 http://lists.freebsd.org/pipermail/cvs-src/2004-July/026489.html
 http://lists.freebsd.org/pipermail/cvs-src/2004-July/026490.html
 
 In terms of time:
 
 src-sys date=2004.07.02.00.38.00 # no hang
 src-sys date=2004.07.02.00.41.00 # hang

From: Emil Mikulic <g3c7a531@dmr.ath.cx>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/68992: valgrind stuck in umtx state before exit
Date: Wed, 14 Jul 2004 18:32:21 +1000

 It turns out that valgrind uses the "contested" flag (which was
 changed), hard-coding it as a magic number instead of using the (now
 non-existant) UMTX_CONTESTED macro.
 
 Please close this PR.  I'm sorry about the noise (and also about
 doubting the kernel)
 
 Meanwhile, the following patch works for me:
 --- valgrind-current-337-orig/coregrind/vg_proxylwp.c	Fri Apr  9 22:23:30 2004
 +++ valgrind-current-337/coregrind/vg_proxylwp.c	Wed Jul 14 18:27:03 2004
 @@ -28,9 +28,13 @@
     The GNU General Public License is contained in the file COPYING.
  */
  
 -
  #include "vg_include.h"
  
 +#ifndef UMTX_CONTESTED
 +# include <sys/limits.h>
 +# define UMTX_CONTESTED LONG_MIN /* XXX bad */
 +#endif
 +
  /* We need our own copy of VG_(do_syscall)() to handle a special
     race-condition.  If we've got signals unblocked, and we take a
     signal in the gap either just before or after the syscall, we may
 @@ -588,7 +592,7 @@
  
  #if __FreeBSD__ == 5
     VG_(do_syscall)(__NR__umtx_lock, &px->mutex);
 -   px->mutex.u_owner |= 1;	/* XXX set contested bit for simplicity */
 +   px->mutex.u_owner |= UMTX_CONTESTED;	/* XXX set contested bit for simplicity */
     VG_(do_syscall)(__NR_thr_self, &px->lwp);
  #endif
  #if __FreeBSD__ == 4
State-Changed-From-To: open->closed 
State-Changed-By: simon 
State-Changed-When: Wed Jul 14 09:25:08 GMT 2004 
State-Changed-Why:  
Close at submitters request. 

BTW. the FreeBSD kernel isn't bug free so it's ok to doubt it 
sometimes :-). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=68992 
>Unformatted:
