Date: Tue, 6 Jul 1999 10:28:33 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Stephen McKay <syssgm@detir.qld.gov.au> Cc: freebsd-current@freebsd.org, alc@cs.rice.edu, dillon@apollo.backplane.com Subject: Re: Stuck in "objtrm" Message-ID: <14210.4262.296904.751060@grasshopper.cs.duke.edu> In-Reply-To: <199907061044.UAA14043@nymph.detir.qld.gov.au> References: <199907021200.WAA06282@nymph.detir.qld.gov.au> <199907060745.RAA12161@nymph.detir.qld.gov.au> <199907061044.UAA14043@nymph.detir.qld.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
I've occasionally seen systems wedged in a similar state. I reported
my sighting of this on May 24th. Haven't seen it since.
The one bit of useful info I've learned since my report was that from
a talk with the program's author, I suspect the object in question may
have been created with mmap(MAP_ANON,...). I'm not sure if cc1 also
does this, but that may be some common ground..
Stephen McKay writes:
>
> The high points:
> ref_count=0
> shadow_count=0
> type=1 (OBJT_SWAP)
> paging_in_progress=1
> resident_page_count=9
> flags=0x21c8 (onemapping, mightbedirty, writeable, pipwnt, dead)
>
<...>
Similar to mine:
$5 = {
object_list = {
tqe_next = 0xca234244,
tqe_prev = 0xca2ee488
},
shadow_head = {
tqh_first = 0x0,
tqh_last = 0xca1e7a00
},
shadow_list = {
tqe_next = 0x0,
tqe_prev = 0xca29c24c
},
memq = {
tqh_first = 0xc04ff370,
tqh_last = 0xc04e65fc
},
generation = 26962387,
type = OBJT_SWAP,
size = 165,
ref_count = 0,
shadow_count = 0,
pg_color = 60,
hash_rand = -71709939,
flags = 8652,
paging_in_progress = 1,
behavior = 0,
resident_page_count = 51,
cache_count = 0,
wire_count = 0,
backing_object = 0x0,
backing_object_offset = 0,
last_read = 63,
pager_object_list = {
tqe_next = 0xca234244,
tqe_prev = 0xca175970
},
handle = 0x0,
un_pager = {
vnp = {
vnp_size = 5
},
devp = {
devp_pglist = {
tqh_first = 0x5,
tqh_last = 0x0
}
},
swp = {
swp_bcount = 5
}
}
}
>
> Who was watching what code changed recently? Remember I had this problem
> on a kernel from 1999/06/16 too. So it's an "old" problem.
>
> Off to research the next installment...
>
> Stephen.
>
> PS I haven't worked out yet how to find the stack of the errant process.
> Any hints? The stack trace should be helpful.
Yes. say 'proc pidhashtbl[PID & pidhash]->lh_first' in kgdb.
I suspect that it will be in exit() also..
(kgdb) proc pidhashtbl[22207 & pidhash]->lh_first
(kgdb) bt
#0 mi_switch () at ../../kern/kern_synch.c:827
#1 0xc0152cd9 in tsleep (ident=0xca1e79f8, priority=4,
wmesg=0xc024bbca "objtrm", timo=0) at ../../kern/kern_synch.c:443
#2 0xc01f6249 in vm_object_terminate (object=0xca1e79f8)
at ../../vm/vm_object.h:235
#3 0xc01f61f9 in vm_object_deallocate (object=0xca1e79f8)
at ../../vm/vm_object.c:384
#4 0xc01f3ae7 in vm_map_entry_delete (map=0xca1c0380, entry=0xca2b65f0)
at ../../vm/vm_map.c:1887
#5 0xc01f3ca5 in vm_map_delete (map=0xca1c0380, start=0, end=3217022976)
at ../../vm/vm_map.c:1990
#6 0xc01f3d29 in vm_map_remove (map=0xca1c0380, start=0, end=3217022976)
at ../../vm/vm_map.c:2015
#7 0xc014a615 in exit1 (p=0xca2465a0, rv=0) at ../../kern/kern_exit.c:223
#8 0xc014a434 in exit1 (p=0xca2465a0, rv=-904133760)
at ../../kern/kern_exit.c:106
#9 0xc0210dd6 in syscall (frame={tf_fs = 135004207, tf_es = 1209466927,
tf_ds = -1078001617, tf_edi = 0, tf_esi = -1, tf_ebp = -1077947172,
tf_isp = -903335964, tf_ebx = 1209464980, tf_edx = 0, tf_ecx = 0,
tf_eax = 1, tf_trapno = 7, tf_err = 2, tf_eip = 1209204908, tf_cs = 31,
tf_eflags = 582, tf_esp = -1077947196, tf_ss = 47})
at ../../i386/i386/trap.c:1069
#10 0xc0206aa0 in Xint0x80_syscall ()
Drew
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?14210.4262.296904.751060>