Panic in vm_map_stack

[John Baldwin]

On Friday 26 March 2010 3:56:59 pm Kostik Belousov wrote:
> On Fri, Mar 26, 2010 at 06:13:02PM +0000, Tom Judge wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Hi,
> > 
> > I am seeing the following rare but re occurring panic in the
> > vm_map_stack code.
> > 
> > I have the core file and symbols available should more information be
> > required.
> > 
> > Tom
> > 
> > - ----
> > 
> > 
> > > $ uname -a
> > FreeBSD XXX 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4 #0 @718:841: Mon Feb
> > 8 20:14:39 UTC 2010     tj at XXX:/usr/obj/usr/src/sys/XXXv8  amd64
> > 
> > 
> > > $ kgdb /boot/kernel/kernel /var/crash/vmcore.0
> > GNU gdb 6.1.1 [FreeBSD]
> > Copyright 2004 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you 
are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
> > This GDB was configured as "amd64-marcel-freebsd"...
> > 
> > Unread portion of the kernel message buffer:
> > Sleeping thread (tid 100119, pid 1554) owns a non-sleepable lock
> > panic: sleeping thread
> > cpuid = 0
> > Uptime: 44d17h36m22s
> > Physical memory: 32746 MB
> > Dumping 1467 MB: 1452 1436 1420 1404 1388 1372 1356 1340 1324 1308 1292
> > 1276 1260 1244 1228 1212 1196 1180 1164 1148 1132 1116 1100 1084 1068
> > 1052 1036 1020 1004 988 972 956 940 924 908 892 876 860 844 828 812 796
> > 780 764 748 732 716 700 684 668 652 636 620 604 588 572 556 540 524 508
> > 492 476 460 444 428 412 396 380 364 348 332 316 300 284 268 252 236 220
> > 204 188 172 156 140 124 108 92 76 60 44 28 12
> > 
> > #0  doadump () at pcpu.h:195
> > 195	pcpu.h: No such file or directory.
> > 	in pcpu.h
> > (kgdb) bt
> > #0  doadump () at pcpu.h:195
> > #1  0x0000000000000004 in ?? ()
> > #2  0xffffffff8048e2a9 in boot (howto=260) at
> > /usr/src/sys/kern/kern_shutdown.c:418
> > #3  0xffffffff8048e6b2 in panic (fmt=0x104 <Address 0x104 out of
> > bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
> > #4  0xffffffff804c4a95 in propagate_priority (td=Variable "td" is not
> > available.
> > ) at /usr/src/sys/kern/subr_turnstile.c:222
> > #5  0xffffffff804c58a5 in turnstile_wait (ts=Variable "ts" is not 
available.
> > ) at /usr/src/sys/kern/subr_turnstile.c:740
> > #6  0xffffffff804816af in _mtx_lock_sleep (m=0xffffff0654567118,
> > tid=18446742976254672896, opts=Variable "opts" is not available.
> > ) at /usr/src/sys/kern/kern_mutex.c:420
> > #7  0xffffffff80646057 in vm_map_stack (map=0xffffff000447cd00,
> > addrbos=140736951484416, max_ssize=536870912, prot=7 '\a', max=7 '\a',
> > cow=4096) at /usr/src/sys/vm/vm_map.c:2722
> > #8  0xffffffff80467115 in exec_new_vmspace (imgp=0xffffffffb92b4a10,
> > sv=0xffffffff809b0a40) at /usr/src/sys/kern/kern_exec.c:971
> > #9  0xffffffff8044e534 in exec_elf64_imgact (imgp=0xffffffffb92b4a10) at
> > /usr/src/sys/kern/imgact_elf.c:680
> > #10 0xffffffff80467532 in kern_execve (td=0xffffff007a978000,
> > args=0xffffffffb92b4b00, mac_p=Variable "mac_p" is not available.
> > ) at /usr/src/sys/kern/kern_exec.c:432
> > #11 0xffffffff80468477 in execve (td=0xffffff007a978000, uap=Variable
> > "uap" is not available.
> > ) at /usr/src/sys/kern/kern_exec.c:201
> > #12 0xffffffff806d8217 in syscall (frame=0xffffffffb92b4c80) at
> > /usr/src/sys/amd64/amd64/trap.c:907
> > #13 0xffffffff806be2db in Xfast_syscall () at
> > /usr/src/sys/amd64/amd64/exception.S:330
> > #14 0x000000080091bcec in ?? ()
> > Previous frame inner to this frame (corrupt stack?)
> > (kgdb)
> 
> Switch to the thread 100119, and get a backtrace for it.
> You can look up the kgdb thread number by kernel tid by
> issuing "threads" command.

You can also just use 'tid 100119' or 'proc 1554'.

-- 
John Baldwin