From owner-freebsd-current Fri Jul 9 3:35:26 1999 Delivered-To: freebsd-current@freebsd.org Received: from ren.detir.qld.gov.au (ns.detir.qld.gov.au [203.46.81.66]) by hub.freebsd.org (Postfix) with ESMTP id 0D86115234 for ; Fri, 9 Jul 1999 03:35:21 -0700 (PDT) (envelope-from syssgm@detir.qld.gov.au) Received: by ren.detir.qld.gov.au; id UAA02507; Fri, 9 Jul 1999 20:34:05 +1000 (EST) Received: from ogre.detir.qld.gov.au(167.123.8.3) by ren.detir.qld.gov.au via smap (3.2) id xma002503; Fri, 9 Jul 99 20:34:04 +1000 Received: from atlas.detir.qld.gov.au (atlas.detir.qld.gov.au [167.123.8.9]) by ogre.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA09658; Fri, 9 Jul 1999 20:33:25 +1000 (EST) Received: from nymph.detir.qld.gov.au (nymph.detir.qld.gov.au [167.123.10.10]) by atlas.detir.qld.gov.au (8.8.5/8.8.5) with ESMTP id UAA24100; Fri, 9 Jul 1999 20:33:24 +1000 (EST) Received: from nymph.detir.qld.gov.au (localhost.detir.qld.gov.au [127.0.0.1]) by nymph.detir.qld.gov.au (8.8.8/8.8.7) with ESMTP id UAA03176; Fri, 9 Jul 1999 20:33:24 +1000 (EST) (envelope-from syssgm@nymph.detir.qld.gov.au) Message-Id: <199907091033.UAA03176@nymph.detir.qld.gov.au> To: Matthew Dillon Cc: freebsd-current@freebsd.org, syssgm@detir.qld.gov.au Subject: Re: Stuck in "objtrm" - live kernel test to run References: <199907081828.LAA41802@apollo.backplane.com> In-Reply-To: <199907081828.LAA41802@apollo.backplane.com> from Matthew Dillon at "Thu, 08 Jul 1999 11:28:10 -0700" Date: Fri, 09 Jul 1999 20:33:23 +1000 From: Stephen McKay Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 8th July 1999, Matthew Dillon wrote: > There is a way we can find out for sure. For any of you with processes > stuck in objtrm, see if you can gdb the kernel and get a backtrace > of that process to see if it might be in a state where a previous > call context is holding a PIP count on the object. Just for completeness, here's mine again, done with your ps trick: (kgdb) back #0 mi_switch () at ../../kern/kern_synch.c:827 #1 0xc014a5bd in tsleep (ident=0xc32ea21c, priority=4, wmesg=0xc023db84 "objtrm", timo=0) at ../../kern/kern_synch.c:443 #2 0xc01e9741 in vm_object_terminate (object=0xc32ea21c) at ../../vm/vm_object.h:230 #3 0xc01e96f1 in vm_object_deallocate (object=0xc32ea21c) at ../../vm/vm_object.c:382 #4 0xc01e6acb in vm_map_entry_delete (map=0xc3047440, entry=0xc3240190) at ../../vm/vm_map.c:1680 #5 0xc01e6c89 in vm_map_delete (map=0xc3047440, start=0, end=3217022976) at ../../vm/vm_map.c:1783 #6 0xc01e6d1d in vm_map_remove (map=0xc3047440, start=0, end=3217022976) at ../../vm/vm_map.c:1808 #7 0xc0141d20 in exit1 (p=0xc322f0a0, rv=0) at ../../kern/kern_exit.c:220 #8 0xc0141b24 in exit1 (p=0xc322f0a0, rv=-1021614488) at ../../kern/kern_exit.c:106 #9 0xc020e41a in syscall (frame={tf_fs = 47, tf_es = 137297967, tf_ds = -1078001617, tf_edi = 136021320, tf_esi = 0, tf_ebp = -1077947348, tf_isp = -1020915756, tf_ebx = -1, tf_edx = 135690384, tf_ecx = 136200192, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 135656524, tf_cs = 31, tf_eflags = 582, tf_esp = -1077947368, tf_ss = 47}) at ../../i386/i386/trap.c:1056 #10 0xc0202cc0 in Xint0x80_syscall () error reading /proc/27157/mem And for extra points: (kgdb) frame 4 #4 0xc01e6acb in vm_map_entry_delete (map=0xc3047440, entry=0xc3240190) at ../../vm/vm_map.c:1680 1680 vm_object_deallocate(entry->object.vm_object); (kgdb) p/x *entry $10 = {prev = 0xc3047460, next = 0xc3249e38, start = 0x81c6000, end = 0x8458000, avail_ssize = 0x0, object = {vm_object = 0xc32ea21c, sub_map = 0xc32ea21c}, offset = 0x15000, eflags = 0x0, protection = 0x7, max_protection = 0x7, inheritance = 0x1, wired_count = 0x0} I haven't made any clever conclusions from this, but you might do better. > Note: the process cannot be swapped out, so if you've had a process > stuck in objtrm for a long time try doing as "ps axfl" to force it's > upages in and then gdb should be able to backtrace it. The 'f' in the ps > does that. Cute. After the ps axlf, all the swapped out processes went from 0 to 8 KB resident. But the stuck process stayed at 0 KB resident. It wasn't swapped out anyway, according to the ps flags, so it should have had some resident pages. Seems like a contradiction to me. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message