| Summary: | systems panics when ktrace-ing | ||
|---|---|---|---|
| Product: | Base System | Reporter: | assar <assar> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | CC: | assar |
| Priority: | Normal | ||
| Version: | 3.3-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->feedback Does this problem still occur in newer versions of FreeBSD, such as 4.3-RELEASE? Adding to Audit-Trail. ----- Forwarded message from assar@sics.se ----- Delivered-To: mike@freebsd.org From: assar@sics.se To: mike@FreeBSD.org Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/15204: systems panics when ktrace-ing Date: 23 Jul 2001 03:12:45 +0200 In-Reply-To: mike@FreeBSD.org's message of "Sat, 21 Jul 2001 11:18:41 -0700 (PDT)" User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.6 mike@FreeBSD.org writes: > Synopsis: systems panics when ktrace-ing > > State-Changed-From-To: open->feedback > State-Changed-By: mike > State-Changed-When: Sat Jul 21 11:18:22 PDT 2001 > State-Changed-Why: > > Does this problem still occur in newer versions of FreeBSD, > such as 4.3-RELEASE? I've not been able to reproduce this, but that required lots of running last time, so that doesn't really tell us very much. And it seems to me that it would be related to the problem reported in kern/26896. /assar ----- End forwarded message ----- State Changed From-To: feedback->closed kern_ktrace 1.57 sounds like it fixes this problem: Fix ktrace enablement/disablement races that can result in a vnode ref count panic. Bug noticed by: ps Reviewed by: ps MFC after: 1 day If somehow this can still be reproduced, the PR can be reopened. |
System manages to panic when running ktrace. It seems to be caused by the ref-count on the node refered to by `proc' being too low. I'm sorry I don't have more details but I don't have time to look further at this right know and I thought this problem might live better in the PR database than in my leaky memory. IdlePTD 4190208 initial pcb at 36b14c panicstr: lockmgr: locking against myself panic messages: --- panic: lockmgr: locking against myself syncing disks... 21 21 18 11 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 giving up dumping to dev 20001, offset 163840 dump 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 (kgdb) bt #0 boot (howto=256) at ../../kern/kern_shutdown.c:285 #1 0xc016a52d in panic (fmt=0xc02ea4cc "lockmgr: locking against myself") at ../../kern/kern_shutdown.c:446 #2 0xc0165f70 in lockmgr (lkp=0xc0d3b100, flags=16842754, interlkp=0xc3f51f70, p=0xc3f1de40) at ../../kern/kern_lock.c:326 #3 0xc018cec4 in vop_stdlock (ap=0xc3fffdfc) at ../../kern/vfs_default.c:209 #4 0xc0273efd in ufs_vnoperate (ap=0xc3fffdfc) at ../../ufs/ufs/ufs_vnops.c:2299 #5 0xc0195ec7 in vn_lock (vp=0xc3f51f00, flags=65538, p=0xc3f1de40) at vnode_if.h:811 #6 0xc018fb53 in vrele (vp=0xc3f51f00) at ../../kern/vfs_subr.c:1336 #7 0xc027cb53 in vm_object_vndeallocate (object=0xc40214d8) at ../../vm/vm_object.c:277 #8 0xc026cc1b in ffs_write (ap=0xc3fffee8) at ../../ufs/ufs/ufs_readwrite.c:513 #9 0xc0165b4d in ktrwrite (vp=0xc3f51f00, kth=0xc0cb0c00) at vnode_if.h:331 #10 0xc0165462 in ktrsysret (vp=0xc3f51f00, code=93, error=0, retval=1) at ../../kern/kern_ktrace.c:123 #11 0xc02a228c in syscall (frame={tf_es = 39, tf_ds = -1078001625, tf_edi = 0, tf_esi = 1, tf_ebp = -1077945756, tf_isp = -1006632988, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 1, tf_trapno = 7, tf_err = 2, tf_eip = 671854512, tf_cs = 31, tf_eflags = 514, tf_esp = -1077946208, tf_ss = 39}) at ../../i386/i386/trap.c:1148 #12 0xc029731c in Xint0x80_syscall () #13 0x804acca in ?? () #14 0x804a5d5 in ?? () #15 0x8049f45 in ?? () (kgdb) f 10 #10 0xc0165462 in ktrsysret (vp=0xc3f51f00, code=93, error=0, retval=1) at ../../kern/kern_ktrace.c:123 (kgdb) p *vp $1 = {v_flag = 2105344, v_usecount = 0, v_writecount = 0, v_holdcnt = 127, v_lastr = 59, v_id = 516993, v_mount = 0xc0c3b600, v_op = 0xc0bd1100, v_freelist = {tqe_next = 0x0, tqe_prev = 0xc3fa97a0}, v_mntvnodes = { le_next = 0xc3fd6a40, le_prev = 0xc3fe8268}, v_cleanblkhd = { tqh_first = 0xc1ac5ff8, tqh_last = 0xc1a92b10}, v_dirtyblkhd = { tqh_first = 0xc1ac0de0, tqh_last = 0xc1ab02d0}, v_synclist = { le_next = 0xc3f1a780, le_prev = 0xc094b3c4}, v_numoutput = 0, v_type = VREG, v_un = {vu_mountedhere = 0x0, vu_socket = 0x0, vu_specinfo = 0x0, vu_fifoinfo = 0x0}, v_lease = 0x0, v_lastw = 636, v_cstart = 636, v_lasta = 125872, v_clen = 7, v_maxio = 65536, v_object = 0xc40214d8, v_interlock = {lock_data = 0}, v_vnlock = 0x0, v_tag = VT_UFS, v_data = 0xc0d3b100, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xc0ca5580, tqh_last = 0xc0ca5590}, v_cache_dst_count = 1, v_dd = 0xc3f51f00, v_ddid = 0, v_pollinfo = { vpi_lock = {lock_data = 0}, vpi_selinfo = {si_pid = 0, si_flags = 0}, vpi_events = 0, vpi_revents = 0}} Fix: none found yet How-To-Repeat: ktrace -i -p `cat /var/run/inetd.pid' and then do lots of things :-)