Your message dated Fri, 18 May 2012 07:23:57 +1000
with message-id <[email protected]>
and subject line [[email protected]: [procps] bug #627257, top: memory
leaks]
has caused the Debian Bug report #627257,
regarding top: memory leaks
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
627257: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627257
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: procps
Version: 1:3.2.8-10
Severity: important
Hi,
I today noticed that in top, that top eats RAM (rss),
and it incresses. About +8kB per refresh.
It started from about 1MB, and after few minutes
I got 13MB, and it was still climbing.
valgrind also warns me that there are some still reachable
memory.
==12449==
==12449== HEAP SUMMARY:
==12449== in use at exit: 2,138,733 bytes in 49,688 blocks
==12449== total heap usage: 216,526 allocs, 166,838 frees, 290,240,055 bytes
allocated
==12449==
==12449== LEAK SUMMARY:
==12449== definitely lost: 1,849,536 bytes in 48,825 blocks
==12449== indirectly lost: 240 bytes in 20 blocks
==12449== possibly lost: 8,868 bytes in 142 blocks
==12449== still reachable: 280,089 bytes in 701 blocks
==12449== suppressed: 0 bytes in 0 blocks
==12449== Rerun with --leak-check=full to see details of leaked memory
==12449==
==12449== For counts of detected and suppressed errors, rerun with: -v
==12449== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 8)
It is probably releaed to my top configuration,
so I present here a .toprc.
# cat ./.toprc
RCfile for "top with windows" # shameless braggin'
Id:a, Mode_altscr=0, Mode_irixps=1, Delay_time=1.000, Curwin=0
Def fieldscur=AEHIoQTWKNmbcdFGjprsUvLXYZ
winflags=130456, sortindx=13, maxtasks=0
summclr=2, msgsclr=2, headclr=6, taskclr=2
Job fieldscur=ABcefgjlrstuvyzMKNHIWOPQDX
winflags=64825, sortindx=0, maxtasks=0
summclr=6, msgsclr=6, headclr=7, taskclr=6
Mem fieldscur=ANOPQRSTUVbcdefgjlmyzWHIKX
winflags=64825, sortindx=13, maxtasks=0
summclr=5, msgsclr=5, headclr=4, taskclr=5
Usr fieldscur=ABDECGfhijlopqrstuvyzMKNWX
winflags=64825, sortindx=4, maxtasks=0
summclr=3, msgsclr=3, headclr=2, taskclr=3
#
On the other hand on other account where I have different .toprc,
I also have some warnings from valgrind, but memory
usage do not grow, and LEAK SuMMARY is essentially
the same regardless how long I run top
(constant overhead, nothing harmless, as there is no need
to deallocate things if we are exiting anyway).
Regards,
Witek
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.39-rc7-thinkpad-t43-00897-ga2b9c1f-dirty (SMP w/1 CPU core;
PREEMPT)
Locale: LANG=pl_PL.utf8, LC_CTYPE=pl_PL.utf8 (charmap=UTF-8) (ignored: LC_ALL
set to pl_PL.utf8)
Shell: /bin/sh linked to /bin/dash
Versions of packages procps depends on:
ii initscripts 2.88dsf-13.6 scripts for initializing and shutt
ii libc6 2.13-4 Embedded GNU C Library: Shared lib
ii libncurses5 5.9-1 shared libraries for terminal hand
ii libncursesw5 5.9-1 shared libraries for terminal hand
ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip
Versions of packages procps recommends:
ii psmisc 22.13-1 utilities that use the proc file s
procps suggests no packages.
-- Configuration Files:
/etc/sysctl.conf changed [not included]
-- no debconf information
--- End Message ---
--- Begin Message ---
This is the forwarded email from the top upstream programmer. In short
the memory leak is small and makes other parts more efficient.
Therefore I'm closing this bug.
----- Forwarded message from Jim Warner <[email protected]> -----
Hi Craig,
Here's a little more information on the above bug.
The problem began with with this.
. Bug #506303: from Russell Coker <[email protected]>
. Date: Thu, 20 Nov 2008 22:01:53 +1100
. Subject: ps should have an option to display the supplementary groups
The memory leak was created with this reply to that bug.
. Patch: from Alfredo Esteban <[email protected]>
. Date: Wed, 18 Feb 2009 21:25:38 +0100
. Attachment: patch_supplementary_groups.diff
In that diff the library was given the ability to access Groups (supplementary)
in the status2proc function. The library internally called a new external(?)
allocsupgrp function. However, the user of the proc_t, which now potentially
contained extra dynamically acquired memory, was responsible for calling
freesupgrp, another new exported function.
The patch arranged for the ps/display module to dutifully call freesupgrp.
Unfortunately, top was never told about this nasty hack. Thus, when *any*
/proc/#/status field was displayed, poor old top would get hit with Alfredo's
memory leak. In top terms, such fields are those with the L_status or L_EITHER
library flags.
Now, with procps-ng, all dynamic memory management is the responsibility of the
library. That responsibility is discharged when a proc_t is reused and
explains the valgrind "possibly lost" categories. Those are simply proc_t
memory (the proc_t itself plus associated extra memory) that never gets
recycled and/or freed by program end.
There remain, however, some minor valgrind "definitely lost" library memory
leaks for which top again gets blamed. They are associated with the library's
pwcache.c hashing of results from getpwuid and getgrgid calls. So whenever the
functions user_from_uid or group_from_gid are invoked, memory is potentially
acquired that will never be freed. This happens whenever a user/group was not
already hashed.
The amounts for such memory are modest and reach some high water mark dependent
on a particular system at a particular point in time. I've included examples
below. In any case, this is by design and makes perfect sense -- trade a
little memory for reduced function call overhead.
So, could we please swat/squash/kill/bury this bug?
Regards,
Jim
examples of "definitely lost" categories due to hashing
-------------------------------------------------------
300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost...
at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
by 0x5390F76: nss_parse_service_list (nsswitch.c:626)
by 0x5391528: __nss_database_lookup (nsswitch.c:167)
by 0x5C34553: ???
by 0x53444BC: getpwuid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
by 0x5343DAE: getpwuid (getXXbyYY.c:117)
by 0x4E3539E: user_from_uid (pwcache.c:56)
by 0x4E36FA2: simple_readproc (readproc.c:765)
by 0x4E373BD: readproc (readproc.c:1041)
by 0x404EAD: procs_refresh (top.c:2042)
by 0x407346: frame_make (top.c:3849)
by 0x40A46E: main (top.c:3912)
300 (60 direct, 240 indirect) bytes in 1 blocks are definitely lost...
at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
by 0x5390F76: nss_parse_service_list (nsswitch.c:626)
by 0x5391528: __nss_database_lookup (nsswitch.c:167)
by 0x5C3251B: ???
by 0x5342A9C: getgrgid_r@@GLIBC_2.2.5 (getXXbyYY_r.c:256)
by 0x53421EE: getgrgid (getXXbyYY.c:117)
by 0x4E3546E: group_from_gid (pwcache.c:84)
by 0x4E36595: supgrps_from_supgids.clone.0 (readproc.c:430)
by 0x4E370A1: simple_readproc (readproc.c:754)
by 0x4E373BD: readproc (readproc.c:1041)
by 0x404E0E: procs_refresh (top.c:2042)
by 0x407346: frame_make (top.c:3849)
----- End forwarded message -----
--
Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au
Debian GNU/Linux http://www.debian.org/ csmall at : debian.org
GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
--- End Message ---
