procps apps that involve a username have a memory leak

Bug #175605 reported by Brian Beck on 2007-12-11
Affects Status Importance Assigned to Milestone
glibc (Ubuntu)

Bug Description

Binary package hint: procps

Applications in the procps package that involve a username (w, ps u, etc) have a memory leak. I think it occurs during the user_from_uid() function. Here's a valgrind summary on w.

$ valgrind --leak-check=full w
==24028== ERROR SUMMARY: 192 errors from 53 contexts (suppressed: 21 from 1)
==24028== malloc/free: in use at exit: 89,824 bytes in 285 blocks.
==24028== malloc/free: 2,033 allocs, 1,748 frees, 220,678 bytes allocated.
==24028== For counts of detected errors, rerun with: -v
==24028== searching for pointers to 285 not-freed blocks.
==24028== checked 228,528 bytes.
==24028== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 1 of 6
==24028== at 0x4022765: malloc (vg_replace_malloc.c:149)
==24028== by 0x41419B2: (within /lib/tls/i686/cmov/
==24028== by 0x4142208: __nss_database_lookup (in /lib/tls/i686/cmov/
==24028== by 0x43DFFDB: ???
==24028== by 0x43E111C: ???
==24028== by 0x40EEEEB: getpwuid_r (in /lib/tls/i686/cmov/
==24028== by 0x40EE89D: getpwuid (in /lib/tls/i686/cmov/
==24028== by 0x4041B60: user_from_uid (in /lib/
==24028== LEAK SUMMARY:
==24028== definitely lost: 36 bytes in 1 blocks.
==24028== indirectly lost: 120 bytes in 10 blocks.
==24028== possibly lost: 0 bytes in 0 blocks.
==24028== still reachable: 89,668 bytes in 274 blocks.
==24028== suppressed: 0 bytes in 0 blocks.
==24028== Reachable blocks (those to which a pointer was found) are not shown.
==24028== To see them, rerun with: --leak-check=full --show-reachable=yes

If there's anything I can do to help please let me know.

Version: 1:3.2.7-3ubuntu5


Brian Beck (brian-beck) wrote :

O.k. I'm moving this bug to the glibc package. I'm doing this because I noticed that the leak isn't limited to the procps package. If you do a "valgrind --leak-check=full ls -l" you will notice that it too is leaking memory. Running ls without user names does not show a memory leak.

Colin Watson (cjwatson) wrote :

I'm fairly sure that this is the once-per-process allocation for the purpose of parsing nsswitch.conf, and thus only matters at all in that it produces valgrind noise. I'm not even sure that this should be considered a bug, except perhaps in that valgrind should ignore it.

Changed in glibc:
importance: Undecided → Low
Brian Beck (brian-beck) wrote :

Ah, if that's the case, please don't hesitate to close it (Invalid). I didn't mean to add a bogus bug.


What to do with this bug now?

Changed in glibc (Ubuntu):
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

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

Changed in glibc (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers