Fatal trap 12: page fault while in kernel mode

[Robert Watson]

On Sat, 6 Jan 2007, Marc G. Fournier wrote:

> Just had the following happen on a FreeBSD 6.2-PRERELEASE #7: Sun Dec 17 
> 01:28:52 AST 2006 system ... amd64, HP Proliant, 6G of RAM ... have core if 
> there is information that I can provide out of it ...
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x18c
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xffffffff801f9053
> stack pointer           = 0x10:0xffffffffb5c78b30
> frame pointer           = 0x10:0xffffffffb5c78b60
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 5 (thread taskq)
> trap number             = 12
> panic: page fault
> cpuid = 0
> Uptime: 8d22h25m40s
>
> (kgdb) where
> #0  doadump () at pcpu.h:172
> #1  0xffffffff80203955 in boot (howto=260) at
> /usr/src/sys/kern/kern_shutdown.c:409
> #2  0xffffffff80204065 in panic (fmt=0xffffff019b667720
> "X\223f\233\001ÿÿÿ\020µc\233\001ÿÿÿ") at
> /usr/src/sys/kern/kern_shutdown.c:565
> #3  0xffffffff803287a6 in trap_fatal (frame=0xc, eva=18446742981100074784) at
> /usr/src/sys/amd64/amd64/trap.c:660
> #4  0xffffffff80328cd8 in trap (frame=
>      {tf_rdi = 112, tf_rsi = -1092609476832, tf_rdx = 6, tf_rcx = 3221225730,
> tf_r8 = -1245213424, tf_r9 = -1092609476832, tf_rax = 1, tf_rbx =
> - -1096874331952, tf_rbp = -1245213856, tf_r10 = -2142258536, tf_r11 = 0, tf_r12
> = 4, tf_r13 = -1092609476832, tf_r14 = 4, tf_r15 = 1, tf_trapno = 12, tf_addr =
> 396, tf_flags = -2145197496, tf_err = 0, tf_rip = -2145415085, tf_cs = 8,
> tf_rflags = 65538, tf_rsp = -1245213888, tf_ss = 16}) at
> /usr/src/sys/amd64/amd64/trap.c:238
> #5  0xffffffff80313c6b in calltrap () at
> /usr/src/sys/amd64/amd64/exception.S:168
> #6  0xffffffff801f9053 in _mtx_lock_sleep (m=0xffffff009d31f0d0,
> tid=18446742981100074784, opts=6, file=0xc0000102 <Address 0xc0000102 out of
> bounds>, line=-1245213424) at /usr/src/sys/kern/kern_mutex.c:546
> #7  0xffffffff8025b1ac in unp_gc (arg=0x70, pending=-1687783648) at
> /usr/src/sys/kern/uipc_usrreq.c:1714
> #8  0xffffffff8022c314 in taskqueue_run (queue=0xffffff0000844800) at
> /usr/src/sys/kern/subr_taskqueue.c:257
> #9  0xffffffff8022d0e7 in taskqueue_thread_loop (arg=0x70) at
> /usr/src/sys/kern/subr_taskqueue.c:376
> #10 0xffffffff801e7b76 in fork_exit (callout=0xffffffff8022d060
> <taskqueue_thread_loop>, arg=0xffffffff805030d0, frame=0xffffffffb5c78c50) at
> /usr/src/sys/kern/kern_fork.c:821
> #11 0xffffffff80313fce in fork_trampoline () at
> /usr/src/sys/amd64/amd64/exception.S:394

This is a NULL pointer dereference in the UNIX domain socket code.  John 
Baldwin recently committed a fix for a bug with these symptoms to 7-CURRENT, 
with an MFC planned in the near future.  The fix won't make 6.2-RELEASE, but 
assuming it tests out well over the next few weeks, we will cut an errata 
patch/announcement for it.  I believe you can pull down his 6-STABLE version 
at:

   http://people.FreeBSD.org/~jhb/patches/unp_gc.patch

This same patch is currently in texting on mx1.FreeBSD.org.

(John CC'd)

Robert N M Watson
Computer Laboratory
University of Cambridge