[indiana-discuss] [perf-discuss] Memory leak somewhere, maybe in libc (libc_hwcap2.so.1 / SXCE b105 x64) ?
Bart Smaalders
bart.smaalders at Sun.COM
Wed Feb 11 19:47:55 PST 2009
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:
: barts at 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
barts at cyber.eng.sun.com http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
More information about the indiana-discuss
mailing list