kern/68992: valgrind stuck in umtx state before exit

[Emil Mikulic]

The following reply was made to PR kern/68992; it has been noted by GNATS.

From: Emil Mikulic <g3c7a531 at dmr.ath.cx>
To: freebsd-gnats-submit at 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