On Sun, May 09, 2004 at 01:06:09AM -0700, Kris Kennaway wrote: > A package build machine just died with the following: > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x6c > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc06cf6e0 > stack pointer = 0x10:0xe32c9c70 > frame pointer = 0x10:0xe32c9ce4 > 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 = 76798 (javadoc) > kernel: type 12 trap, code=0 > > mmap(c7c65bd0,e32c9d14,20,434,8) at mmap+0x2a0 > syscall(805002f,280f002f,bfbf002f,8059330,825a415) at syscall+0x2a0 > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (198, FreeBSD ELF32, nosys), eip = 0x281785a4, esp = 0xbfbfd80c, ebp = 0xbfbfd858 --- After a conversation on IRC, it was established that mmap+0x2a0 was: #9 0xc06cf6e0 in mmap (td=0xc7c65bd0, uap=0xe32c9d14) at ../../../vm/vm_mmap.c:323 323 if (vp->v_mount->mnt_flag & MNT_NOEXEC) And: (kgdb) print fp->f_vnode $1 = (struct vnode *) 0xc9c0fe38 (kgdb) print fp->f_vnode->v_mount $2 = (struct mount *) 0x0 (kgdb) print fp->f_vnode->v_op $3 = (vop_t **) 0xc61ff700 (kgdb) print fp->f_vnode->v_type $4 = VCHR (kgdb) print spec_vnodeop_p $5 = (vop_t **) 0xc61ff700 (kgdb) print fp->f_vnode->v_tag $6 = 0xc0772c0e "orphanchr" This is a character device vnode that has been orphaned from the filesystem containing its special file by a forced unmount. mmap() should check that v_mount != NULL before dereferencing it to handle this case properly. I'll commit a fix for this soon if nobody beats me to it. TimReceived on Sat May 08 2004 - 23:50:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:53 UTC