Date: Fri, 2 Jul 2004 18:11:19 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-threads@freebsd.org Subject: Re: odd KSE panic Message-ID: <Pine.GSO.4.10.10407021757160.2618-100000@pcnet5.pcnet.com> In-Reply-To: <16613.53106.413179.808734@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10407021757160.2618-100000>