On 05-17 21:42, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the procps package:
>
> #627257: top: memory leaks
>
> It has been closed by Craig Small <csm...@debian.org>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Craig Small
> <csm...@debian.org> by
> replying to this email.
>
>
> --
> 627257: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627257
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
Received: (at 627257-done) by bugs.debian.org; 17 May 2012 21:41:17 +0000
X-Spam-Checker-Version: SpamAssassin 3.3.1-bugs.debian.org_2005_01_02
(2010-03-16) on busoni.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-3.0 required=4.0 tests=BAYES_00,FROMDEVELOPER,GMAIL,
MURPHY_DRUGS_REL8,RDNS_DYNAMIC,TO_NO_BRKTS_DYNIP autolearn=no
version=3.3.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 66; hammy, 151; neutral, 237; spammy,
0. spammytokens: hammytokens:0.000-+--H*u:1.5.21, 0.000-+--H*UA:1.5.21,
0.000-+--H*u:2010-09-15, 0.000-+--H*UA:2010-09-15, 0.000-+--UD:diff
Return-path: <csm...@enc.com.au>
Received: from ppp121-44-205-190.lns20.syd7.internode.on.net ([121.44.205.190]
helo=mail.enc.com.au)
by busoni.debian.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
(Exim 4.72)
(envelope-from <csm...@enc.com.au>)
id 1SV8Rg-0001u1-CZ
for 627257-d...@bugs.debian.org; Thu, 17 May 2012 21:41:17 +0000
Received: by mail.enc.com.au (Postfix, from userid 1000)
id 52B7D2F23C; Fri, 18 May 2012 07:23:57 +1000 (EST)
Date: Fri, 18 May 2012 07:23:57 +1000
From: Craig Small <csm...@debian.org>
To: 627257-d...@bugs.debian.org
Subject: [james.war...@comcast.net: [procps] bug #627257, top: memory leaks]
Message-ID: <20120517212356.ga19...@enc.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Greylist: delayed 596 seconds by postgrey-1.32 at busoni; Thu, 17 May 2012
21:41:16 UTC
>
> 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 <james.war...@comcast.net> -----
> Hi Craig,
>
> Here's a little more information on the above bug.
>
> The problem began with with this.
> . Bug #506303: from Russell Coker <russ...@coker.com.au>
> . 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 <aedelato...@gmail.com>
> . 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?
Hello,
Are you kiding? I reported this problem becuase top after week of
working was using almost 1GB of RAM! This is modest amount of memory?
Please implement some garbage collection at least for this hashing. I
can accept O(1) memory lost associated with initialization or something
allocated once, including things which are limited like user/group
names, but not anything which grows constantly in time when running any
program, like top have main loop and each time loop end something is definitely
lost.
I do not know if bug is sitll reproductible with newer version of top,
but it was previously the case. I cannot reproduce it in this moment,
but will try with different top configuration.
Regards,
Witek
--
Witold Baryluk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
