[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pthread-mutex debugging (PR#44387)
-----BEGIN PGP SIGNED MESSAGE-----
On Sep 22, 2012, at 3:20 PM, Frank Wille wrote:
today I spent some time on debugging PR #44387 (some pthread mutex
run forever). As Jeff Rizzo wrote, the problem disappears when
a kernel with DIAGNOSTIC option.
I could now isolate the problem on sys/kern/kern_mutex.c. It was
sufficient to compile kern_mutex.c with -DFULL to make the problem
disappear. The rest of the kernel was compiled without DIAGNOSTIC.
FULL enables the use of __cpu_simple_lock_try() and
when locking/unlocking a mutex, which sets/unsets a variable in an
Unfortunately I still don't see what is wrong here. I fear the problem
is somewhere else and using the "full" locking code hides it somehow.
Hmm, I wonder if this is somehow related to the SMP problems we still
have on macppc ( I didn't try just DIAGNOSTIC in a long time though,
so I don't know if that helps. I'll try next chance I get. A while ago
I had to run with LOCKDEBUG in order to get it halfway stable. ) -
lots of filesystem activity gets processes stuck in all sorts of funny
ways ( which I don't see on sparc64 or amd64 SMP ), not necessarily in
anything filesystem related and it can take anything between 5 minutes
and a whole build.sh distribution to show up. I long suspected that
there's something wrong with locking primitives or related code but
couldn't prove it or figure out what exactly goes wrong.
Running with just one CPU online makes the problems go away.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: GPGTools - http://gpgtools.org
-----END PGP SIGNATURE-----
Main Index |
Thread Index |