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
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
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 Close at submitters request. BTW. the FreeBSD kernel isn't bug free so it's ok to doubt it sometimes :-).