Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Oct 1999 12:20:01 -0700 (PDT)
From:      David Gilbert <dgilbert@velocet.ca>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/14141: 3.3-RELEASE crashing often
Message-ID:  <199910101920.MAA81395@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/14141; it has been noted by GNATS.

From: David Gilbert <dgilbert@velocet.ca>
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199910101920.MAA81395>