Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Jul 1999 13:59:06 -0400 (EDT)
From:      "Brian F. Feldman" <green@FreeBSD.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        Stephen McKay <syssgm@detir.qld.gov.au>, freebsd-current@FreeBSD.org, alc@cs.rice.edu, dillon@apollo.backplane.com
Subject:   Re: Stuck in "objtrm" 
Message-ID:  <Pine.BSF.4.10.9907061357380.4140-100000@janus.syracuse.net>
In-Reply-To: <14210.4262.296904.751060@grasshopper.cs.duke.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 

 Brian Fundakowski Feldman      _ __ ___ ____  ___ ___ ___  
 green@FreeBSD.org                   _ __ ___ | _ ) __|   \ 
     FreeBSD: The Power to Serve!        _ __ | _ \._ \ |) |
       http://www.FreeBSD.org/              _ |___/___/___/ 



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?Pine.BSF.4.10.9907061357380.4140-100000>