top appears to leak memory

Bug #743350 reported by lindelof
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
procps (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: procps

I always have a top screen open, and after a while the memory usage reported by top for itself grows larger and larger. It is now almost as large as GIMP and larger than Firefox. See attached screenshot.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: procps 1:3.2.8-9ubuntu3
ProcVersionSignature: Ubuntu 2.6.35-28.49-generic 2.6.35.11
Uname: Linux 2.6.35-28-generic x86_64
NonfreeKernelModules: wl
Architecture: amd64
Date: Sat Mar 26 23:25:52 2011
ExecutablePath: /usr/bin/top
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.utf8
SourcePackage: procps

Revision history for this message
lindelof (lindelof) wrote :
Revision history for this message
Jon Skanes (jon-skanes) wrote :
Download full text (22.2 KiB)

I can confirm this. `top` leaks well over 100M in a day for me. The following valgrind run was for just a minute or two:

==730==
==730== HEAP SUMMARY:
==730== in use at exit: 289,823 bytes in 2,860 blocks
==730== total heap usage: 13,186 allocs, 10,326 frees, 1,839,594 bytes allocated
==730==
==730== 6 bytes in 1 blocks are still reachable in loss record 1 of 39
==730== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==730== by 0x412146F: strdup (strdup.c:43)
==730== by 0x40920FA: _nc_setupterm (lib_setup.c:701)
==730== by 0x4092482: setupterm (lib_setup.c:816)
==730== by 0x804E959: whack_terminal (top.c:1971)
==730== by 0x8054C50: main (top.c:3396)
==730==
==730== 8 bytes in 1 blocks are indirectly lost in loss record 2 of 39
==730== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==730== by 0x418E5DB: __nss_lookup_function (nsswitch.c:356)
==730== by 0x4610ECB: ???
==730== by 0x4611B6C: ???
==730== by 0x414541C: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==730== by 0x4144D4E: getpwuid (getXXbyYY.c:117)
==730== by 0x404738C: user_from_uid (pwcache.c:42)
==730== by 0x4048959: simple_readproc (readproc.c:600)
==730== by 0x4049483: readproc (readproc.c:838)
==730== by 0x804C5EA: procs_refresh (top.c:1167)
==730== by 0x80511BE: summary_show (top.c:2998)
==730== by 0x8054A1A: frame_make (top.c:3351)
==730==
==730== 8 bytes in 1 blocks are indirectly lost in loss record 3 of 39
==730== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==730== by 0x418E5DB: __nss_lookup_function (nsswitch.c:356)
==730== by 0x4610EE9: ???
==730== by 0x4611B6C: ???
==730== by 0x414541C: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==730== by 0x4144D4E: getpwuid (getXXbyYY.c:117)
==730== by 0x404738C: user_from_uid (pwcache.c:42)
==730== by 0x4048959: simple_readproc (readproc.c:600)
==730== by 0x4049483: readproc (readproc.c:838)
==730== by 0x804C5EA: procs_refresh (top.c:1167)
==730== by 0x80511BE: summary_show (top.c:2998)
==730== by 0x8054A1A: frame_make (top.c:3351)
==730==
==730== 8 bytes in 1 blocks are indirectly lost in loss record 4 of 39
==730== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==730== by 0x418E5DB: __nss_lookup_function (nsswitch.c:356)
==730== by 0x4610F07: ???
==730== by 0x4611B6C: ???
==730== by 0x414541C: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==730== by 0x4144D4E: getpwuid (getXXbyYY.c:117)
==730== by 0x404738C: user_from_uid (pwcache.c:42)
==730== by 0x4048959: simple_readproc (readproc.c:600)
==730== by 0x4049483: readproc (readproc.c:838)
==730== by 0x804C5EA: procs_refresh (top.c:1167)
==730== by 0x80511BE: summary_show (top.c:2998)
==730== by 0x8054A1A: frame_make (top.c:3351)
==730==
==730== 8 bytes in 1 blocks are indirectly lost in loss record 5 of 39
==730== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==730== by 0x418E5DB: __nss_lookup_function (nsswitch.c:356)
==730== by 0x4610F25: ???
==730== by 0x4611B6C: ???
==730== by 0x414541C: getpwuid_r@@GLIBC_2.1.2 (getXXbyYY_r.c:253)
==730== by 0x4144D4E: getpwuid (getXXbyYY.c:117)
==730== by 0x404738C: user_from_uid (pwcac...

tags: added: x86
Revision history for this message
Jon Skanes (jon-skanes) wrote :

Here is my system info:

Distributor ID: Ubuntu
Description: Ubuntu 10.10
Release: 10.10
Codename: maverick

Linux nano 2.6.35-25-generic-pae #44-Ubuntu SMP Fri Jan 21 19:01:46 UTC 2011 i686 GNU/Linux

procps: 1:3.2.8-9ubuntu3
libncurses5: 5.7+20100626-0ubuntu1
libc6: 2.12.1-0ubuntu10.2

.toprc:
RCfile for "top with windows" # shameless braggin'
Id:a, Mode_altscr=1, Mode_irixps=0, Delay_time=5.000, Curwin=0
Def fieldscur=AEHIOQTWKNMbcdfgjplrsuvyzX
        winflags=32697, sortindx=10, maxtasks=11
        summclr=1, msgsclr=1, headclr=3, taskclr=1
Job fieldscur=ABcefgjlrstuvyzMKNHIWOPQDX
        winflags=32697, sortindx=10, maxtasks=0
        summclr=6, msgsclr=6, headclr=7, taskclr=6
Mem fieldscur=ANOPQRSTUVbcdefgjlmyzWHIKX
        winflags=32697, sortindx=16, maxtasks=0
        summclr=5, msgsclr=5, headclr=4, taskclr=5
Usr fieldscur=ABDECGfhijlopqrstuvyzMKNWX
        winflags=32697, sortindx=10, maxtasks=0
        summclr=3, msgsclr=3, headclr=2, taskclr=3

Changed in procps (Ubuntu):
status: New → Confirmed
Revision history for this message
Jon Skanes (jon-skanes) wrote :

This is still happening in Natty.

Revision history for this message
Bryan Quigley (bryanquigley) wrote :

Is this still an issue for any of you in Ubuntu 12.04?

Changed in procps (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for procps (Ubuntu) because there has been no activity for 60 days.]

Changed in procps (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Stevel (stevel-launchpad) wrote :

I've been running top for a few days on a 'forgotten' tty. Now it's using over 3GB of memory...

Changed in procps (Ubuntu):
status: Expired → Confirmed
Revision history for this message
Stevel (stevel-launchpad) wrote :

for the record, running Ubuntu 12.04 LTS with procps version 1:3.2.8-11ubuntu6.3

Revision history for this message
jim warner (warnerjc) wrote :

Please see message #44 in the following closed debian bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627257

The memory leak you've experienced was eliminated with the advent procps-ng release 3.3.0.

Trusty 14.04 is now using procps-ng release 3.3.9.

Regards.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.