Re: Reproducable Panic on CURRENT and 6.0-RELEASE

On Friday 16 December 2005 03:27 pm, Anish Mistry wrote:
> On Friday 16 December 2005 03:11 pm, you wrote:
> > On Friday 16 December 2005 12:37 pm, Anish Mistry wrote:
> > > Here is the offending program/code.  The interesting program is
> > > avidemux_2.1_branch_anish/avidemux/avidemux2.
> > > (It is compiled for CURRENT, and I left all the object code stuff
> > > in so it's a bit large 21MB)
> > > http://am-productions.biz/docs/avidemux_2.1_branch_anish.tgz
> > >
> > > First you'll need to compile spidermonkey to be threadsafe so add
> > > the following to your lang/spidermonkey/Makefile before
> > > installing it: LIB_DEPENDS=    nspr4.1:${PORTSDIR}/devel/nspr
> > > MAKE_ARGS+=     JS_THREADSAFE=YES LDFLAGS="-L${LOCALBASE}/lib
> > > -lpthread -lm"
> > > CFLAGS+=        -I${LOCALBASE}/include/nspr
> > >
> > > Once a threadsafe spidermonkey is installed to kill the machine
> > > you'll need to:
> > > cd avidemux_2.1_branch_anish/avidemux
> > > ./avidemux2 --run new-features-test.js
> > >
> > > On CURRENT:
> > > kernel trap 12 with interrupts disabled
> > >
> > > Fatal trap 12: page fault while in kernel mode
> > > fault virtual address   = 0x68
> > > fault code              = supervisor read, page not present
> > > instruction pointer     = 0x20:0xc04e6f36
> > > stack pointer           = 0x28:0xcc9edb3c
> > > frame pointer           = 0x28:0xcc9edbb0
> > > code segment            = base 0x0, limit 0xfffff, type 0x1b
> > >                         = DPL 0, pres 1, def32 1, gran 1
> > > processor eflags        = resume, IOPL = 0
> > > current process         = 798 (gdb)
> > > trap number             = 12
> > > panic: page fault
> > >
> > > #0  doadump () at pcpu.h:165
> > > #1  0xc04bb7eb in boot (howto=260)
> > > at /usr/src/sys/kern/kern_shutdown.c:399
> > > #2  0xc04bb353 in panic (fmt=0xc06069a7 "%s")
> > >     at /usr/src/sys/kern/kern_shutdown.c:555
> > > #3  0xc05e91ba in trap_fatal (frame=0xcc9edafc, eva=104)
> > >     at /usr/src/sys/i386/i386/trap.c:862
> > > #4  0xc05e96d9 in trap (frame=
> > >       {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1032878460,
> > > tf_esi = 1, tf_ebp = -862004304, tf_isp = -862004440, tf_ebx =
> > > -1033297504, tf_edx = -1033987232, tf_ecx = 4, tf_eax = 0,
> > > tf_trapno = 12, tf_err = 0, tf_eip = -1068601546, tf_cs = 32,
> > > tf_eflags = 65687, tf_esp = -1032878356, tf_ss = -1067380424})
> > >     at /usr/src/sys/i386/i386/trap.c:273
> > > #5  0xc05db6fa in calltrap ()
> > > at /usr/src/sys/i386/i386/exception.s:137
> > > #6  0xc04e6f36 in kern_ptrace (td=0xc25e9b60, req=10, pid=1,
> > > addr=0x0, data=17)
> > >     at /usr/src/sys/kern/sys_process.c:802
> >
> > On HEAD this is:
> > 				p->p_xthread->td_flags &= ~TDF_XSIG;
> >
> > If two threads called kern_ptrace() with the same PID and this
> > could happen. Hmm, I have no idea how p_xthread is supposed to not
> > be racey here in fact. It would be helpful to know what PTRACE
> > action it it is trying to do and maybe a KTR trace of the various
> > ptrace events leading up to this condition. I have no idea what
> > thread you are supposed to act on if p_xthread is NULL either.
>
> How would I do this?  My kdb/ddb skills are prettymuch limited to
> getting a backtrace.

You could add some new KTR tracepoints to log each request into kern_ptrace() 
and then do a 'show ktr' at the ddb prompt.


-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org