Date: Tue, 27 May 1997 16:35:57 +0200 From: Tor Egge <Tor.Egge@idi.ntnu.no> To: karl@Mcs.Net Cc: rb@gid.co.uk, current@FreeBSD.ORG Subject: Re: Boom! :-) Message-ID: <199705271435.QAA14136@pat.idt.unit.no> In-Reply-To: Your message of "Mon, 26 May 1997 18:24:06 -0500" References: <19970526182406.59864@Jupiter.Mcs.Net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <lockinit>: pushl %ebp 0xe0116031 <lockinit+1>: movl %esp,%ebp 0xe0116033 <lockinit+3>: pushl %esi 0xe0116034 <lockinit+4>: pushl %ebx 0xe0116035 <lockinit+5>: movl 0x8(%ebp),%eax 0xe0116038 <lockinit+8>: movl 0xc(%ebp),%edx 0xe011603b <lockinit+11>: movl 0x10(%ebp),%ecx 0xe011603e <lockinit+14>: movl 0x14(%ebp),%ebx 0xe0116041 <lockinit+17>: movl 0x18(%ebp),%esi 0xe0116044 <lockinit+20>: andl $0x70,%esi 0xe0116047 <lockinit+23>: movl %esi,0x4(%eax) 0xe011604a <lockinit+26>: movl $0x0,0x8(%eax) 0xe0116051 <lockinit+33>: movl $0x0,0xc(%eax) 0xe0116058 <lockinit+40>: movw $0x0,0x10(%eax) 0xe011605e <lockinit+46>: movw %dx,0x12(%eax) 0xe0116062 <lockinit+50>: movl %ecx,0x14(%eax) 0xe0116065 <lockinit+53>: movl %ebx,0x18(%eax) 0xe0116068 <lockinit+56>: movl $0xffffffff,0x1c(%eax) 0xe011606f <lockinit+63>: leal 0xfffffff8(%ebp),%esp 0xe0116072 <lockinit+66>: popl %ebx 0xe0116073 <lockinit+67>: popl %esi 0xe0116074 <lockinit+68>: leave 0xe0116075 <lockinit+69>: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705271435.QAA14136>