On Tue, 6 Jul 1999, Andrew Gallatin wrote:
>
>
> 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..
For what it's worth, our RTLD and malloc() both use mmap(,,,MAP_ANON,,);.
>
>
> 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 [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
>
Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve! _ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
