On Fri, Jun 27, 2008 at 02:18:24PM -0700, Bill Stouder-Studenmund wrote:
> I've got the wrstuden-revivesa branch to where kernels boot and almost
> work. A test program is running into an error that is "letting" me debug
> error handling.
>
> I'm running into a LOCKDEBUG error that makes no sense:
>
> printf("About to destroy sa_mutex %p\n", &sa->sa_mutex);
> mutex_destroy(&sa->sa_mutex);
> printf("Did destroy sa_mutex %p\n", &sa->sa_mutex);
> pool_put(&sadata_pool, sa);
>
> is triggering a lockdebug error that "sa" contains a still-active lock.
> I'm attaching a screen shot of the problem seen running in VM Fusion. The
> deal is that the lock that's causing the problem, 0xcbbe6f78, is the very
> lock that was passed to mutex_destroy(). I have printfs before and after
> the destroy showing that it sure looks like it was zapped.
Turns out the problem was there was a mutex_init() call followed by a
memset(sa, 0, sizeof(*sa)) call sequence. That wiped out MUTEX_BIT_DEBUG
in the mutex, which caused the mutex_destroy() code to not tell the
lockdebug code about the destroy, since it thought the mutex wasn't being
debugged.
Take care,
Bill
Attachment:
pgpJ6XoI7dpIh.pgp
Description: PGP signature