Date: Tue, 25 May 1999 21:09:02 -0400 From: "David E. Cross" <crossd@cs.rpi.edu> To: hackers@freebsd.org Subject: kernel debugging assistance Message-ID: <199905260109.VAA93769@cs.rpi.edu>
next in thread | raw e-mail | index | archive | help
I am trying to trace down the cause of the recursive lock and I stumbled upon
this:
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc014b3f4 in at_shutdown (
function=0xc0234aca <__set_sysuninit_set_sym_M_KTRACE_uninit_sys_uninit+154>, arg=0x10002, queue=-951064448) at ../../kern/kern_shutdown.c:446
#2 0xc01470f8 in lockmgr (lkp=0xc10d8f00, flags=16842754,
interlkp=0xc74fe8f0, p=0xc743eb20) at ../../kern/kern_lock.c:326
#3 0xc016cfbc in vop_stdlock (ap=0xc7482a64) at ../../kern/vfs_default.c:209
#4 0xc01e4fad in ufs_vnoperate (ap=0xc7482a64)
at ../../ufs/ufs/ufs_vnops.c:2299
#5 0xc0175d97 in vn_lock (vp=0xc74fe880, flags=65538, p=0xc743eb20)
at vnode_if.h:811
#6 0xc016f93f in vget (vp=0xc74fe880, flags=2, p=0xc743eb20)
at ../../kern/vfs_subr.c:1274
#7 0xc016bac7 in vfs_cache_lookup (ap=0xc7482b24)
at ../../kern/vfs_cache.c:439
#8 0xc01e4fad in ufs_vnoperate (ap=0xc7482b24)
at ../../ufs/ufs/ufs_vnops.c:2299
#9 0xc016e079 in lookup (ndp=0xc7482d94) at vnode_if.h:31
#10 0xc01b769c in nfs_namei (ndp=0xc7482d94, fhp=0xc7482d0c, len=3,
slp=0xc0f7e600, nam=0xc0f54200, mdp=0xc7482c48, dposp=0xc7482c44,
retdirp=0xc7482c2c, p=0xc743eb20, kerbflag=0, pubflag=0)
at ../../nfs/nfs_subs.c:1642
#11 0xc01a068f in nfsrv_lookup (nfsd=0xc1185700, slp=0xc0f7e600,
procp=0xc743eb20, mrq=0xc7482e34) at ../../nfs/nfs_serv.c:396
#12 0xc01b90f6 in nfssvc_nfsd (nsd=0xc7482e94, argp=0x8071af4 "", p=0xc743eb20)
at ../../nfs/nfs_syscalls.c:656
#13 0xc01b8a11 in nfssvc (p=0xc743eb20, uap=0xc7482f94)
at ../../nfs/nfs_syscalls.c:342
#14 0xc020bd5f in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi = 8,
tf_esi = 0, tf_ebp = -1077944892, tf_isp = -951570460, tf_ebx = 0,
tf_edx = -1077945288, tf_ecx = 0, tf_eax = 155, tf_trapno = 12,
tf_err = 2, tf_eip = 134518940, tf_cs = 31, tf_eflags = 642,
tf_esp = -1077945280, tf_ss = 39}) at ../../i386/i386/trap.c:1100
#15 0xc0202b8c in Xint0x80_syscall ()
#16 0x80480e9 in ?? ()
(kgdb) up 3
#3 0xc016cfbc in vop_stdlock (ap=0xc7482a64) at ../../kern/vfs_default.c:209
209 return (lockmgr(l, ap->a_flags, &ap->a_vp->v_interlock, ap->a_p));
(kgdb) print ap
$1 = (struct vop_lock_args *) 0x0
(kgdb)
That doesn't seem to be possible, especially since ap->FOO is used in the same
line.. wouldn't that cause a fault at this point? (it isn't the panic
occurs later as you can see.)
--
David Cross | email: crossd@cs.rpi.edu
Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd
Rensselaer Polytechnic Institute, | Ph: 518.276.2860
Department of Computer Science | Fax: 518.276.4033
I speak only for myself. | WinNT:Linux::Linux:FreeBSD
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905260109.VAA93769>