Date: Mon, 25 Feb 2002 18:40:07 +0000 From: Ian Dowse <iedowse@maths.tcd.ie> To: Kris Kennaway <kris@obsecurity.org> Cc: mckusick@mckusick.com, fs@FreeBSD.org, dillon@FreeBSD.org, fanf@chiark.greenend.org.uk Subject: Re: UFS panic on -stable Message-ID: <200202251840.aa88376@salmon.maths.tcd.ie> In-Reply-To: Your message of "Mon, 25 Feb 2002 01:40:28 PST." <20020225014028.A53147@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020225014028.A53147@xor.obsecurity.org>, Kris Kennaway writes: >Is there anything else I can provide? I don't have any real idea where to start, but the following information from frame 11 (ffs_freefile) would be useful. The alternatives are in case gdb is confused by register variables. *pvp [or *(struct vnode *)0xce24d180] *pip [or *(struct inode *)pvp->v_data] *fs [or *pip->i_fs] *bp *cgp [or *(struct cg *)bp->b_data] inosused[400/8] [or *((char *)cgp + cgp->cg_iusedoff + 50)] inosused[0]@200 From frame 18 (fdrop), "*p" and "*fp" might help to give some context too. Actually, one thing that does stand out (I think) is the value of `mode' in the ffs_freefile and ffs_vfree arguments. This is 0666 in octal, but should it not include some IFMT bits too? I would have expected it to be 0100666 (33206) instead. Maybe something is managing to change the mode of an inode after it has been already freed, causing the (ip->i_mode == 0) check in ufs_inactive to draw the wrong conclusion? #11 0xc02ad7ce in ffs_freefile (pvp=0xce24d180, ino=400, mode=438) at ../../ufs/ffs/ffs_alloc.c:1611 #12 0xc02ad652 in ffs_vfree (pvp=0xce24d180, ino=400, mode=438) at ../../ufs/ffs/ffs_alloc.c:1566 Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200202251840.aa88376>