RE: panic: sleeping thread owns a mutex

On 28-Jul-2003 Kris Kennaway wrote:
> One of the alpha package machines just died with the following:
> 
> panic: sleeping thread owns a mutex
> panic() at panic+0x160
> propagate_priority() at propagate_priority+0x148
> _mtx_lock_sleep() at _mtx_lock_sleep+0x264
> _mtx_lock_flags() at _mtx_lock_flags+0x84
> _vm_map_lock() at _vm_map_lock+0x40
> vm_map_remove() at vm_map_remove+0x34
> kmem_free() at kmem_free+0x34
> pipe_free_kmem() at pipe_free_kmem+0xbc
> pipeclose() at pipeclose+0x188
> pipe_close() at pipe_close+0x40
> fdrop_locked() at fdrop_locked+0x180
> fdrop() at fdrop+0x50
> closef() at closef+0x260
> fdfree() at fdfree+0x3c4
> exit1() at exit1+0x578
> sys_exit() at sys_exit+0x58
> syscall() at syscall+0x338
> XentSys() at XentSys+0x64
> --- syscall (1, FreeBSD ELF64, sys_exit) ---
> --- user mode ---
> db>
> 
> (gdb -k is still broken on alpha, so I can't do better).  The machine
> is running a kernel from June 20.

The only way to track these down is to use witness.  By the time
we get here it becomes a lot harder to track down.  It does look
to be alc_at_'s fault since it is a vm_map mutex however.  To get
better info, you are going to need to do the following in ddb when
it panics:

- Examine the mutex structure to find the lock owner, then examine
  the thread structure to find the proc pointer, and finally,
  examine the proc structure to find the pid.

  - or -

- Change the panic message to print the PID.  I just committed this.

Then:

- trace <pid> to see where it slept

-- 

John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/