On Sat, 16 Apr 2011, Jukka Ruohonen wrote:
On Thu, Apr 14, 2011 at 06:27:19AM -0700, Paul Goyette wrote:The fault is coming from the following code at lines 817-821 of src/sys/kern/kern_descrip.c (rev. 1.212, in which christos@ touched the close-on-exec stuff) if (fp->f_ops != NULL) { error = (*fp->f_ops->fo_close)(fp); } else { error = 0; }Now that this is diagnosed, any idea how to fix this regression that broke the whole test infrastructure?
I'm not totally sure it is diagnosed completely. For example, although the fp->f_ops pointer points to invalid memory address, we don't know how it got there.
If there is any additional info required to help narrow this down, I am more than willing to work on it. I still have the qemu virtual machine in this state...
uvm_fault(0xffffffff80ca65e0, 0xffffffff80eff000, 1) -> e fatal page fault in supervisor mode trap type 6 code 0 rip ffffffff80464902 cs 8 rflags 286 cr2 ffffffff80effaf0 cpl 0 rsp ffff80000b72b9e0 kernel: page fault trap, code=0 Stopped in pid 12792.19 (rumpnfsd) at netbsd:closef+0x5d: call *0x30(%rax) ? db{0}> bt closef() at netbsd:closef+0x5d fd_free() at netbsd:fd_free+0xb5 exit1() at netbsd:exit1+0x10e sigexit() at netbsd:sigexit+0x182 postsig() at netbsd:postsig+0xc5 lwp_userret() at netbsd:lwp_userret+0x15c syscall() at netbsd:syscall+0x13a db{0}>
------------------------------------------------------------------------- | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -------------------------------------------------------------------------