odd KSE panic

Daniel Eischen eischen at vigrid.com
Fri Jul 2 15:11:23 PDT 2004


On Fri, 2 Jul 2004, Andrew Gallatin wrote:

> 
> Daniel Eischen writes:
>  > On Fri, 2 Jul 2004, Andrew Gallatin wrote:
> 
>  > > The interesting thing is that there is no stack..  Just one function
>  > > from my driver (mx_free()) sitting out there by itself.  Is the kernel
>  > > somehow ripping the kernel stacks of all threads out from under them
>  > > when one thread calls exit()?  How do I take a reference so I
>  > > don't risk getting marooned without a stack?
>  > 
>  > exit() exits the process, including reaping all kernel threads.
>  > I'm not sure why one thread (worker) doing an exit() will
>  > still allow other threads to continue running.  You should
>  > be using pthread_exit() to exit from the worker thread,
>  > but that still doesn't explain why you're having the problem.
>  > 
> 
> Thanks.. I'm calling pthread_exit() now.  Still having a problem.
> 
> What can you tell about the state of threads from this ddb info:
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address   = 0x0
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc1d69193
> stack pointer           = 0x10:0x0
> frame pointer           = 0x10:0x0
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 1937 (mx_loopback_test)
> kernel: type 12 trap, code=0
> kernel trap 12 with interrupts disabled
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address   = 0x0
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc0651e11
> stack pointer           = 0x10:0xfffffefc
> frame pointer           = 0x10:0xffffff1c
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 1937 (mx_loopback_test)
> kernel: type 12 trap, code=0
> Stopped at      kdb_trap+0x151: movl    0x40(%edx),%eax
> 
> db> ps
>  pid   proc     uarea   uid  ppid  pgrp  flag   stat  wmesg    wchan  cmd
>  1937 c1c5a898 e6319000 1387   643  1937 000c002 (threaded)   mx_loopback_test
>    thread 0xc21cec60 ksegrp 0xc182c580 [SLPQ kserel 0xc182c5dc][SLP]
>    thread 0xc21cedc0 ksegrp 0xc1cf1c00 [SLPQ ksesigwait 0xc1c5a998][SLP]
>    thread 0xc1b962c0 ksegrp 0xc182c580 [CPU 1][kse 0xc2161360]

The second thread (0xc21cedc0) is the special signal handler thread.
It's of no real interest here.

> db> sho thread  0xc21cec60
> Proc 0xc1c5a898    thread 0xc21cec60 ksegrp 0xc182c580 [SLPQ kserel 0xc182c5dc][SLP]
> sched_switch(c21cec60,df262f7,22c29cb3,ffc03014,c21cec60) at sched_switch+0xbc
> mi_switch(1,c052c35e,c182c5dc,c1c5a898,0) at mi_switch+0x1a2
> sleepq_switch(c182c5dc,0,0,e8474c98,c0512cef) at sleepq_switch+0x169
> sleepq_timedwait_sig(c182c5dc,0,c1c5a904,c069e850,0) at sleepq_timedwait_sig+0x17
> msleep(c182c5dc,c1c5a904,168,c069e850,ea61) at msleep+0x490
> kse_release(c21cec60,e8474d14,4,c04f102e,1) at kse_release+0x288
> syscall(2f,2f,2f,8052200,0) at syscall+0x2f0
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (383, FreeBSD ELF32, kse_release), eip = 0x280941a7, esp = 0x8193f90, ebp = 0x8193fcc ---
> 
> 
> db> sho thread 0xc1b962c0 
> Proc 0xc1c5a898    thread 0xc1b962c0 ksegrp 0xc182c580 [CPU 1][kse 0xc2161360]
> kdb_trap(c,0,ffffffc0,1,1) at kdb_trap+0x151
> trap_fatal(ffffffc0,0,1,0,c1b962c0) at trap_fatal+0x2e3
> trap_pfault(ffffffc0,0,0,0,0) at trap_pfault+0x22d
> trap(18,10,10,0,c16c8ce0) at trap+0x2dd
> calltrap() at calltrap+0x5
> --- trap 0xc, eip = 0xc1d69193, esp = 0, ebp = 0 ---
> mx_free() at mx_free+0x1b
> db> 

Do you know which thread is doing the mx_free()?  Is it the worker
thread?  If you are calling in to the kernel to wakeup the worker
thread, it may be possible for the worker thread to return and
run before the calling thread returns from the kernel and runs.

-- 
Dan Eischen



More information about the freebsd-threads mailing list