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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.) Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040613040646.GB28627>