Date: Wed, 15 Sep 2004 10:58:59 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: current@FreeBSD.org Cc: jhb@FreeBSD.org Subject: Possible NULL pointer deref in sched_add() via maybe_preempt() and kse_release() Message-ID: <Pine.NEB.3.96L.1040915105648.89730A-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Got this today on an SMP box running mysql:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x150
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc06224de
stack pointer = 0x10:0xef1b1b28
frame pointer = 0x10:0xef1b1b38
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = resume, IOPL = 0
current process = 572 (mysqld)
db> trace
sched_add(0,3) at sched_add+0x16
setrunqueue(c27867d0,3) at setrunqueue+0x15f
sched_switch(c27867d0,c2a93af0,2) at sched_switch+0xf2
mi_switch(2,c2a93af0,c2a93c44,c2a93af0,ef1b1bf4) at mi_switch+0x1b2
maybe_preempt(c2a93af0) at maybe_preempt+0x93
sched_add(c2a93af0,0) at sched_add+0x103
setrunqueue(c2a93af0,0) at setrunqueue+0x15f
turnstile_unpend(c2960c40,c2785c40,c27867d0,ef1b1c78,c062efdc) at
turnstile_unpend+0x25f
_mtx_unlock_sleep(c2785cac,0,0,0) at _mtx_unlock_sleep+0x6c
sleepq_catch_signals(c26f0c80,0,0,100,c2930260) at
sleepq_catch_signals+0x134
msleep(c26f0c80,c2785cac,168,c081471e,7f) at msleep+0x239
kse_release(c27867d0,ef1b1d14,1,8a,206) at kse_release+0x237
syscall(a89002f,830002f,bfa9002f,8304000,0) at syscall+0x283
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (383, FreeBSD ELF32, kse_release), eip = 0x2833aa1b, esp =
0x8308f88, ebp = 0x8308fc4 ---
db> show pcpu
cpuid = 0
curthread = 0xc27867d0: pid 572 "mysqld"
curpcb = 0xef1b1da0
fpcurthread = none
idlethread = 0xc2260960: pid 14 "idle: cpu0"
APIC ID = 0
currentldt = 0x30
The source code here is probably about a day old; the panic occurred
during a kernel build using an NFS-mounted source tree and local object
tree. MySQL should have been basically idle, since no clients were active
or had been active recently, but no doubt it wakes up once in a while to
do something.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040915105648.89730A-100000>