James,
Thanks for the analysis!
Indeed. It is either someone calls dladm_read_conf() without calling
dladm_destroy_conf(), or there is some bug in the relative logic in
dlmgmtd itself.
Bug 6949971 is filed for this. I'll take it on.
Thanks
- Cathy
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.
_______________________________________________
networking-discuss mailing list
[email protected]
