Giovanni Tirloni wrote:
> 
> 
> On Tue, May 4, 2010 at 7:17 PM, Yun Zhou <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     I just realized that James didn't reply to all.

Sorry about that.  I was intentionally sending the comment to Cathy
personally, since I wasn't very sure it was the right path, and I didn't
want to add confusion for the user.

> r...@hm2706:~# mdb ./core.4310
> Loading modules: [ libumem.so.1 libavl.so.1 ld.so.1 ]
>> ::findleaks
> findleaks: no memory leaks detected

It's a leak of sorts.  It's adding entries to an AVL tree endlessly.

> ::umausers
105584384 bytes for 1649756 allocations with data size 64:
         libumem.so.1`umem_cache_alloc_debug+0x144
         libumem.so.1`umem_cache_alloc+0x19a
         libumem.so.1`umem_alloc+0xcd
         libumem.so.1`malloc+0x2a
         libumem.so.1`calloc+0x4a
         linkattr_set+0x74
         dlmgmt_readconf+0x8a
         dlmgmt_handler+0xec
32995120 bytes for 412439 allocations with data size 80:
         libumem.so.1`umem_cache_alloc_debug+0x144
         libumem.so.1`umem_cache_alloc+0x19a
         libumem.so.1`umem_alloc+0xcd
         libumem.so.1`malloc+0x2a
         libumem.so.1`calloc+0x4a
         dlconf_create+0x1f
         dlmgmt_readconf+0x5f
         dlmgmt_handler+0xec
[...]
> dlmgmt_dlconf_avl::walk avl ! wc -l
  412440

The short answer would probably be "don't do that."  These appear to be
due to clients reading the configuration over and over again.

-- 
James Carlson         42.703N 71.076W         <[email protected]>
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to