Hi All, I’m going to try to put this bug to rest, once and for all.
The top memory leak was serious, but top was a victim, not the culprit. A fuller explanation can be found in message #27, which unfortunately is not line wrapped thus making it more difficult to read. So I’ll summarize here: 1) A poorly designed patch adding supplementary group support to ps resulted in the library dynamically acquiring additional memory whenever /proc/#/status was accessed. 2) It was up to the caller to explicitly free that memory, which the ps program dutifully did. 3) Nobody bothered to inform the top program of this requirement so whenever that directory was accessed, memory would be leaked. It didn’t always happen but required one of these fields to be displayed: PPID, RUSER, S or COMMAND. All of that was fixed under procps-ng with release 3.3.0. However, there remains these 2 valgrind "lost" categories, neither of which represent unintended memory leaks: 4) "definitely lost" This is memory associated with the hashing in pwcache.c of results from getpwuid and getgrgid calls. By design, memory is acquired that will never be freed if a user or group was not already hashed. 5) "possibly lost" This is simply all of the dynamic memory (like that discussed above) plus the proc_t’s themselves representing the last top refresh cycle. Since the program is ending, such memory will be freed automatically. When Craig stated in message #27 that "the memory leak is small and makes other parts more efficient" , he was referring to points 4 & 5 above only. Unfortunately, Witold thought he was referring to the real leak discussed under points 1-3. Please, close this darn bug. Regards, Jim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
