[indiana-discuss] [perf-discuss] Memory leak somewhere, maybe in libc (libc_hwcap2.so.1 / SXCE b105 x64) ?

[Jason King]

On Wed, Feb 11, 2009 at 9:37 PM, Jason King <jason.brian.king at gmail.com> wrote:
> On Wed, Feb 11, 2009 at 9:24 PM, Martin Bochnig <martin at martux.org> wrote:
>> Hi!
>>
>> On Thu, Feb 12, 2009 at 4:05 AM, Bob Friesenhahn
>> <bfriesen at simple.dallas.tx.us> wrote:
>>
>>> Your 'top' program obviously has some sort of bug but otherwise I don't see
>>> anything necessarily out of the ordinary in the top listings.
>>
>>
>> Does this explain why a wget process grew to 2.2GB (where I killed it) ??
>> Then wget must have exactly the same bug, which is unlikely. Therefore
>> the bug must be in a shared lib which both use. This suggests (but is
>> not limited to) libc.
>

Have you considered using libumem + gcore to get a list of possible culprits?

>
>>
>>
>>> Some releases
>>> of top work much better under Solaris than others.  Top is a very handy tool
>>> but neither 'SIZE' or 'RES' is indicative of a problem.  For example 'SIZE'
>>> is increased by simply memory mapping a file or device since it is based on
>>> the number of allocated virtual memory pages.  Virtual memory pages may be
>>> shared between processes.  RES is a bit more useful since it indicates the
>>> amount of those virtual memory pages which are mapped into RAM, but it is
>>> also misleading since pages may remain mapped into RAM due to lack of
>>> pressure for memory (from other processes) as well as pressure from memory
>>> from the running process.
>>
>> Yes. But I also checked with a csw-version of top.
>> I decided, however, to attach screenshots depicting the version of top
>> which ships as part of SXCE, as reference (because it has probably
>> been ARC-reviewed and co-checked a 100 times).
>>
>>> If you want to learn more about how memory is
>>> being used by a Solaris process, then see 'pmap'.
>>
>> Okay, let me read its man page. But first, here is its current output
>> for one of the still running wget processes:
>>
>> # pmap 11017
>> 11017:  wget -m -p -k www.opensolaris.org
>> 11017:  wget -m -p -k www.opensolaris.org
>> 08045000      12K rw---    [ stack ]
>> 08050000     208K r-x--  /usr/bin/wget
>> 08093000      20K rwx--  /usr/bin/wget
>> 08098000  553652K rwx--    [ heap ]
>> FEB10000      64K rwx--    [ anon ]
>> FEB23000       4K rwxs-    [ anon ]
>> FEB30000      24K rwx--    [ anon ]
>> FEB40000    1276K r-x--  /usr/lib/libc/libc_hwcap2.so.1
>> FEC8F000      32K rwx--  /usr/lib/libc/libc_hwcap2.so.1
>> FEC97000       8K rwx--  /usr/lib/libc/libc_hwcap2.so.1
>> FECA0000       4K rwx--    [ anon ]
>> FECB0000    1276K r-x--  /lib/libcrypto.so.0.9.8
>> FEDFF000      88K rw---  /lib/libcrypto.so.0.9.8
>> FEE15000      12K rw---  /lib/libcrypto.so.0.9.8
>> FEE20000     264K r-x--  /lib/libssl.so.0.9.8
>> FEE72000      16K rw---  /lib/libssl.so.0.9.8
>> FEE80000     624K r-x--  /lib/libnsl.so.1
>> FEF2C000      24K rw---  /lib/libnsl.so.1
>> FEF32000      20K rw---  /lib/libnsl.so.1
>> FEF40000      56K r-x--  /lib/libsocket.so.1
>> FEF5E000       4K rw---  /lib/libsocket.so.1
>> FEF70000       4K rwx--    [ anon ]
>> FEF80000       4K r-x--  /lib/libdl.so.1
>> FEF90000       4K r-x--  /lib/libmd5.so.1
>> FEFA0000       4K r-x--  /lib/libintl.so.1
>> FEFB0000       4K rwx--    [ anon ]
>> FEFBD000     184K r-x--  /lib/ld.so.1
>> FEFFB000       8K rwx--  /lib/ld.so.1
>> FEFFD000       4K rwx--  /lib/ld.so.1
>>  total    557904K
>> #
>>
>> So, as you can see it has 545MB on Heap.
>>> It does seem a bit unusual that any swap is used at all.  Double check to
>>> make sure that you have not copied a bunch of large files to /tmp since /tmp
>>> comes out of the total memory/swap budget.
>>
>> Sure, thanks.
>> But of course I don't use /tmp for storing big files anymore (as this
>> box has 2.4 TB of ZFS storage). And also no big file got stored there
>> by FireFox's download manager or stuff like that.
>>
>> Proof:
>>
>> bash-3.2$ du -h /tmp
>>  12K   /tmp/.removable
>>   4K   /tmp/hsperfdata_root
>>   4K   /tmp/.X11-unix
>>   4K   /tmp/.X11-pipe
>>  36K   /tmp/hsperfdata_noaccess
>>  28K   /tmp/plugtmp-1
>>   4K   /tmp/.ICE-unix
>>   4K   /tmp/fam-martin
>>   4K   /tmp/x
>>   8K   /tmp/plugtmp
>>   4K   /tmp/hsperfdata_martin
>>   4K   /tmp/65535_sun_studio_12
>>   4K   /tmp/plugtmp-2
>>   8K   /tmp/plugtmp-3
>>   8K   /tmp/.vbox-martin-ipc
>>   8K   /tmp/plugtmp-4
>>  31M   /tmp
>> bash-3.2$
>>
>>> Perhaps the algorithm that 'wget' uses requires a lot of memory to keep
>>> track of things, or perhaps the version you are using has a memory leak.
>>>
>>> Bob
>>
>>
>> I use the default versions shipping with SXCE (/usr/bin/top and
>> /usr/sfw/bin/wget)
>>
>> 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?
>>
>> %martin
>> _______________________________________________
>> perf-discuss mailing list
>> perf-discuss at opensolaris.org
>>
>