top appears to leak memory

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...

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

This is still happening in Natty.

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

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

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

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

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.