From owner-freebsd-bugs Sun Oct 10 12:21:45 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id AAC54157AA for ; Sun, 10 Oct 1999 12:20:07 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA81395; Sun, 10 Oct 1999 12:20:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Date: Sun, 10 Oct 1999 12:20:01 -0700 (PDT) Message-Id: <199910101920.MAA81395@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: David Gilbert Subject: Re: kern/14141: 3.3-RELEASE crashing often Reply-To: David Gilbert Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/14141; it has been noted by GNATS. From: David Gilbert To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: kern/14141: 3.3-RELEASE crashing often Date: Sun, 10 Oct 1999 15:15:38 -0400 (EDT) This is very worrysome. What we seem to have here is memory corruption of some sort, I think (but years of sysadm has dulled by gdb usage)... From a simlar, but hour later crash dump: (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 #1 0xc014aad1 in panic (fmt=0xc02385ba "page fault") at ../../kern/kern_shutdown.c:446 #2 0xc0209712 in trap_fatal (frame=0xcc332ecc, eva=43) at ../../i386/i386/trap.c:942 #3 0xc02093cb in trap_pfault (frame=0xcc332ecc, usermode=0, eva=43) at ../../i386/i386/trap.c:835 #4 0xc0208ffe in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1051776000, tf_esi = -1051100288, tf_ebp = -869060820, tf_isp = -869060876, tf_ebx = 1863, tf_edx = -1050021888, tf_ecx = 0, tf_eax = 31, tf_trapno = 12, tf_err = 2, tf_eip = -1072417321, tf_cs = 8, tf_eflags = 66050, tf_esp = -1051614208, tf_ss = -1050004480}) at ../../i386/i386/trap.c:437 #5 0xc01435d7 in fdcopy (p=0xcc304f40) at ../../kern/kern_descrip.c:951 #6 0xc014587b in fork1 (p1=0xcc304f40, flags=-2147483596) at ../../kern/kern_fork.c:379 #7 0xc014533b in vfork (p=0xcc304f40, uap=0xcc332f94) at ../../kern/kern_fork.c:109 #8 0xc020995b in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 226316880, tf_esi = 226066288, tf_ebp = -1077949592, tf_isp = -869060636, tf_ebx = 673171048, tf_edx = 226250768, tf_ecx = 672877149, tf_eax = 66, tf_trapno = 12, tf_err = 2, tf_eip = 672936705, tf_cs = 31, tf_eflags = 518, tf_esp = -1077949636, tf_ss = 39}) at ../../i386/i386/trap.c:1100 #9 0xc01feedc in Xint0x80_syscall () (kgdb) frame 5 #5 0xc01435d7 in fdcopy (p=0xcc304f40) at ../../kern/kern_descrip.c:951 951 (*fpp)->f_count++; (kgdb) p fpp $1 = (struct file **) 0x0 (kgdb) l 946 bcopy(fdp->fd_ofiles, newfdp->fd_ofiles, i * sizeof(struct file **)); 947 bcopy(fdp->fd_ofileflags, newfdp->fd_ofileflags, i * sizeof(char)); 948 fpp = newfdp->fd_ofiles; 949 for (i = newfdp->fd_lastfile; i-- >= 0; fpp++) 950 if (*fpp != NULL) 951 (*fpp)->f_count++; 952 return (newfdp); 953 } 954 955 /* (kgdb) p newfdp $2 = (struct filedesc *) 0xc1597b80 (kgdb) p *newfdp $3 = {fd_ofiles = 0xc169d000, fd_ofileflags = 0xc16a3400 "", fd_cdir = 0xcc3b5bc0, fd_rdir = 0xcc1cfe00, fd_nfiles = 6400, fd_lastfile = 3912, fd_freefile = 6, fd_cmask = 18, fd_refcnt = 1} now... this implies that fpp somehow gets set to NULL, but: (kgdb) p **(newfdp->fd_ofiles) $7 = {f_list = {le_next = 0xc1696fc0, le_prev = 0xc1567b00}, f_flag = 1, f_type = 1, f_count = 41, f_msgcount = 0, f_cred = 0xc0e27200, f_ops = 0xc024a294, f_seqcount = 1, f_nextread = 0, f_offset = 0, f_data = 0xcc1cde80 ""} (kgdb) p **(newfdp->fd_ofiles+1) $8 = {f_list = {le_next = 0xc13958c0, le_prev = 0xc1419f40}, f_flag = 2, f_type = 1, f_count = 41, f_msgcount = 0, f_cred = 0xc0e27200, f_ops = 0xc024a294, f_seqcount = 1, f_nextread = 0, f_offset = 0, f_data = 0xcc1cde80 ""} (kgdb) p **(newfdp->fd_ofiles+2) $9 = {f_list = {le_next = 0xc13c60c0, le_prev = 0xc139b900}, f_flag = 10, f_type = 1, f_count = 82, f_msgcount = 0, f_cred = 0xc0e27200, f_ops = 0xc024a294, f_seqcount = 1, f_nextread = 0, f_offset = 26016907, f_data = 0xcc27b2c0 ""} Then I thought about it... and fpp itself should not become NULL in this case... it's being incremented from some valid pointer value. Ideas? Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =========================================================GLO================ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message