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? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert_at_fledge.watson.org Senior Research Scientist, McAfee ResearchReceived on Sat Jun 12 2004 - 13:33:39 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:57 UTC