From owner-freebsd-bugs Thu Jan 16 11:28:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA08374 for bugs-outgoing; Thu, 16 Jan 1997 11:28:57 -0800 (PST) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA08359 for ; Thu, 16 Jan 1997 11:28:50 -0800 (PST) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id UAA03197; Thu, 16 Jan 1997 20:27:32 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.8.4/8.6.9) id UAA15648; Thu, 16 Jan 1997 20:17:57 +0100 (MET) Message-ID: Date: Thu, 16 Jan 1997 20:17:57 +0100 From: j@uriah.heep.sax.de (J Wunsch) To: spatula@gulf.net (Prisoner) Cc: freebsd-bugs@freefall.freebsd.org Subject: Re: kern/2494: page faults References: <199701151330.FAA29407@freefall.freebsd.org> X-Mailer: Mutt 0.55-PL10 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199701151330.FAA29407@freefall.freebsd.org>; from Prisoner on Jan 15, 1997 05:30:02 -0800 Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Prisoner wrote: > The page fault is almost always exactly the same. Here's the debugger > information from the last (and most common) fault: > > fault virtual address = 0x7200c4c > fault code = supervisor read, page not present > instruction pointer = 0x8:0xf017c4b4 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = trace/trap, interrupt enabled, resume, IOPL=0 > current process = 4 (update) > interrupt mask = > kernel: type 12 trap, code=0 > breakpoint at _ffs_update +0xa4: cmpl $0x1,0x52c(%ebx) > > It's always within a few instructions to this location. That's in /sys/ufs/ffs/ffs_inode.c: int ffs_update(ap) struct vop_update_args /* { struct vnode *a_vp; struct timeval *a_access; struct timeval *a_modify; int a_waitfor; } */ *ap; { [...] fs = ip->i_fs; /* * Ensure that uid and gid are correct. This is a temporary * fix until fsck has been changed to do the update. */ if (fs->fs_inodefmt < FS_44INODEFMT) { /* XXX */ ^^^^ here Maybe this raises a flag for someone? OTOH, if it were a genuine bug in the code, it should happen reproducibly at the same location, not just ``somewhere around''... The fault VA looks suspicious, it's not just a NULL pointer. It's 0x7200c4c - 0x52c = 0x7200720. Looks like trashed memory -- a pointer has been trashed by repeatedly dumping the short 0x720 over it. Incidentally, 0x720 is a space in the video frame buffer, with the default attribute 0x7 (white gray on black). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)