Date: Fri, 09 Jul 1999 20:33:23 +1000 From: Stephen McKay <syssgm@detir.qld.gov.au> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-current@freebsd.org, syssgm@detir.qld.gov.au Subject: Re: Stuck in "objtrm" - live kernel test to run Message-ID: <199907091033.UAA03176@nymph.detir.qld.gov.au> In-Reply-To: <199907081828.LAA41802@apollo.backplane.com> from Matthew Dillon at "Thu, 08 Jul 1999 11:28:10 -0700" References: <199907081828.LAA41802@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907091033.UAA03176>