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>