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]