Date: Sun, 13 Jun 2004 14:06:46 +1000 From: Tim Robbins <tjr@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: current@freebsd.org Subject: Re: Fatal trap 12 in kern/kern_descrip.c:2346 Message-ID: <20040613040646.GB28627@cat.robbins.dropbear.id.au> In-Reply-To: <Pine.NEB.3.96L.1040612111520.90086B-100000@fledge.watson.org> References: <20040612140758.GA44899@peter.osted.lan> <Pine.NEB.3.96L.1040612111520.90086B-100000@fledge.watson.org>
index | next in thread | previous in thread | raw e-mail
On Sat, Jun 12, 2004 at 11:30:28AM -0400, Robert Watson wrote: > > On Sat, 12 Jun 2004, Peter Holm wrote: > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x4 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc062ec65 > > stack pointer = 0x10:0xd126ab88 > > frame pointer = 0x10:0xd126abc8 > > 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 = 28142 (sysctl) > > kernel: type 12 trap, code=0 > > Stopped at sysctl_kern_file+0x105: movl 0x4(%eax),%eax > > db> t > > sysctl_kern_file(c08d9320,0,0,d126ac10,d126ac10) at sysctl_kern_file+0x105 > > sysctl_root(0,d126ac7c,2,d126ac10,c1a252c0) at sysctl_root+0x156 > > userland_sysctl(c1a252c0,d126ac7c,2,bfbf26c0,bfbfe338) at userland_sysctl+0x12c > > __sysctl(c1a252c0,d126ad14,18,434,6) at __sysctl+0xb3 > > syscall(2f,2f,2f,2,bfbf26c0) at syscall+0x2a0 > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x280bb05b, esp = 0xbfbf265c > > Well, this is certainly a NULL pointer dereference in the sysctl code > exporting file descriptor information to user space (perhaps for fstat?). > The question is what is NULL. It looks like you have a dump -- could you > convert sysctl_kern_file+0x105 to a line number? It's likely that it is > line 2346 of kern_descrip.c, which follows the process pointer to its > ucred. If so, could you use gdb on the dump to inspect *p? ISTR he included the output of "print *p" on his web page. I think the problem here is that we put processes onto the allproc list in fork1() before they're properly initialised (or we unlock the allproc sx too early.) Timhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040613040646.GB28627>