From owner-freebsd-current Tue May 27 07:36:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA15984 for current-outgoing; Tue, 27 May 1997 07:36:54 -0700 (PDT) Received: from pat.idt.unit.no (0@pat.idt.unit.no [129.241.103.5]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA15970 for ; Tue, 27 May 1997 07:36:43 -0700 (PDT) Received: from idt.unit.no (tegge@ikke.idi.ntnu.no [129.241.111.65]) by pat.idt.unit.no (8.8.5/8.8.5) with ESMTP id QAA14136; Tue, 27 May 1997 16:35:58 +0200 (MET DST) Message-Id: <199705271435.QAA14136@pat.idt.unit.no> To: karl@Mcs.Net Cc: rb@gid.co.uk, current@FreeBSD.ORG Subject: Re: Boom! :-) In-Reply-To: Your message of "Mon, 26 May 1997 18:24:06 -0500" References: <19970526182406.59864@Jupiter.Mcs.Net> X-Mailer: Mew version 1.06 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 27 May 1997 16:35:57 +0200 From: Tor Egge Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hmmm... Don't think so... this looks to be in lockinit... [...] > f01119a0 F kern_lock.o > f01119a0 T _lockinit > f01119e8 T _lockstatus > f0111b14 T _lockmgr > f0112068 T _lockmgr_printinfo > f01120d0 F kern_lockf.o Do you have a disassembly of the lockinit function ? virtual address 0x44 looks very much like the lk_exclusivecount member of the lock structure, when a pointer to a struct inode, struct iso_inode, or a struct denode is a NULL pointer. ---- 0xe0116030 : pushl %ebp 0xe0116031 : movl %esp,%ebp 0xe0116033 : pushl %esi 0xe0116034 : pushl %ebx 0xe0116035 : movl 0x8(%ebp),%eax 0xe0116038 : movl 0xc(%ebp),%edx 0xe011603b : movl 0x10(%ebp),%ecx 0xe011603e : movl 0x14(%ebp),%ebx 0xe0116041 : movl 0x18(%ebp),%esi 0xe0116044 : andl $0x70,%esi 0xe0116047 : movl %esi,0x4(%eax) 0xe011604a : movl $0x0,0x8(%eax) 0xe0116051 : movl $0x0,0xc(%eax) 0xe0116058 : movw $0x0,0x10(%eax) 0xe011605e : movw %dx,0x12(%eax) 0xe0116062 : movl %ecx,0x14(%eax) 0xe0116065 : movl %ebx,0x18(%eax) 0xe0116068 : movl $0xffffffff,0x1c(%eax) 0xe011606f : leal 0xfffffff8(%ebp),%esp 0xe0116072 : popl %ebx 0xe0116073 : popl %esi 0xe0116074 : leave 0xe0116075 : ret ---- (gdb) print &((struct inode *) 0)->i_lock $4 = (struct lock *) 0x34 (gdb) print &((struct iso_node *) 0)->i_lock $6 = (struct lock *) 0x34 (gdb) print &((struct denode *) 0)->de_lock $7 = (struct lock *) 0x34 (gdb) print &((struct vm_map *) 0)->ref_lock $8 = (struct simplelock *) 0x58 (gdb) print &((struct mount *) 0)->mnt_lock $9 = (struct lock *) 0x18 (gdb) print &((struct inode *) 0)->i_lock.lk_exclusivecount $12 = (short int *) 0x44 (gdb) print &((struct vm_map *) 0)->lock $13 = (struct lock *) 0x4 ---- Two strange things: 1. lockinit + 0x10 is not on an instruction boundary. (Note: using this disassembly of the lockinit function). 2. none of struct inode, struct iso_inode, struct denode, struct vm_map or struct mount seems to have the lock at the proper offset in the structure for 0x44 to be the faulting address in lockinit. (Note: using this disassembly of the lockinit function). Will the following sequence of events reproduce the crash ? rlogin (or telnet) to target machine run top in the foreground in that rlogin/telnet session Use ~ . or ESC ] c to close the connection on the target machine. In about 50% of the cases, the machine should crash. If the crash is identical to what you have experienced, this is probably another instance of kern/3581, where this patch might help: ---- Index: spec_vnops.c =================================================================== RCS file: /home/ncvs/src/sys/miscfs/specfs/spec_vnops.c,v retrieving revision 1.39 diff -c -r1.39 spec_vnops.c *** spec_vnops.c 1997/05/01 19:12:22 1.39 --- spec_vnops.c 1997/05/24 00:39:29 *************** *** 595,600 **** --- 595,601 ---- * plus the session), release the reference from the session. */ if (vcount(vp) == 2 && ap->a_p && + (vp->v_flag & VXLOCK) == 0 && vp == ap->a_p->p_session->s_ttyvp) { vrele(vp); ap->a_p->p_session->s_ttyvp = NULL; ---- - Tor Egge