Martin Bochnig wrote:
Both my version of wget shall have a bug and my version of top?
Seriously, how likely is this?
Isn't it more likely that there is a problem in a shared library that
both happen to use?
If this is reproducible, could you employ libumem to get an idea of
where the leaks are occuring?
% export UMEM_DEBUG=default
% LD_PRELOAD=libumem.so.1 wget .....
after a while, use gcore $WGETPID to generate a core from another
window. Attach mdb and run ::findleaks:
: ba...@cyber[9]; mdb /usr/bin/wget core.19356
Loading modules: [ libumem.so.1 ld.so.1 ]
> ::findleaks
CACHE LEAKED BUFCTL CALLER
080b1510 6 080f1218 checking_malloc+0x11
080a9290 1 080c6930 libc_hwcap2.so.1`strdup+0x26
080a9290 1 080c69a8 libc_hwcap2.so.1`strdup+0x26
------------------------------------------------------------------------
Total 8 buffers, 3872 bytes
>
If no leaks are found, allocated memory is still reachable
so use ::umausers to find out the pigs:
> ::umausers
101520 bytes for 1269 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
libc_hwcap2.so.1`strdup+0x26
checking_strdup+0xf
string_set_add+0x23
retrieve_tree+0x37f
main+0x5ed
_start+0x7d
100880 bytes for 1261 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
libc_hwcap2.so.1`strdup+0x26
checking_strdup+0xf
retrieve_tree+0x343
main+0x5ed
_start+0x7d
...
- Bart
--
Bart Smaalders Solaris Kernel Performance
ba...@cyber.eng.sun.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
