Re: Potential memory leaks reported by Valgrind against some frequently used commands
On Tue, Mar 01, 2011 at 08:38:42PM -0600, Ron Johnson wrote: On 03/01/2011 06:19 AM, ximalaya wrote: Hi all, [snip] BTW, I ever tried on Redhat Linux 9, no such problem. This is the interesting part. Is RH keeping their patches, or are upstream and other distros just not determining them worthwhile? Not really. The interesting part is 'was this done with the same version of valgrind?' Note that valgrind has a feature to blacklist false positives and issues (like this one) that don't matter at all. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110302091754.gk3...@celtic.nixsys.be
Potential memory leaks reported by Valgrind against some frequently used commands
Hi, As you may have known, valgrind is a powerful and easy to use tool that can be used to detect many memory management issues on Linux. Details regarding valgrind can be seen here, http://valgrind.org I notice that, valgrind reports memory leaks against some frequently used commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps -ef, ls -latr, top, etc. I post the reports here, hope someone can look into this issue and get it resolved(pay attention to function calls in libc-2.7.so). Environment == OS: debian 5.07 debian:~# uname -a Linux debian 2.6.26-2-686 #1 SMP Sat Nov 20 23:06:30 UTC 2010 i686 GNU/Linux debian:/lib/i686/cmov# gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) debian:/lib/i686/cmov# /usr/local/valgrind/bin/valgrind --version valgrind-3.6.1 Valgrind reports 1. netstat debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full netstat ==2591== ==2591== HEAP SUMMARY: ==2591== in use at exit: 15,122 bytes in 1,125 blocks ==2591== total heap usage: 1,367 allocs, 242 frees, 42,343 bytes allocated ==2591== ==2591== 66 (48 direct, 18 indirect) bytes in 4 blocks are definitely lost in loss record 6 of 11 ==2591==at 0x40221CA: malloc (vg_replace_malloc.c:236) ==2591==by 0x804FE96: ??? (in /bin/netstat) ==2591==by 0x8049E1A: ??? (in /bin/netstat) ==2591==by 0x804A3DC: ??? (in /bin/netstat) ==2591==by 0x804CD14: ??? (in /bin/netstat) ==2591==by 0x4047454: (below main) (in /lib/i686/cmov/libc-2.7.so) ==2591== ==2591== LEAK SUMMARY: ==2591==definitely lost: 48 bytes in 4 blocks ==2591==indirectly lost: 18 bytes in 4 blocks ==2591== possibly lost: 0 bytes in 0 blocks ==2591==still reachable: 15,056 bytes in 1,117 blocks ==2591== suppressed: 0 bytes in 0 blocks ==2591== Reachable blocks (those to which a pointer was found) are not shown. ==2591== To see them, rerun with: --leak-check=full --show-reachable=yes ==2591== ==2591== For counts of detected and suppressed errors, rerun with: -v 2. ps -ef debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full ps -ef ==2597== ==2597== HEAP SUMMARY: ==2597== in use at exit: 966 bytes in 44 blocks ==2597== total heap usage: 390 allocs, 346 frees, 20,255 bytes allocated ==2597== ==2597== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 28 of 30 ==2597==at 0x40221CA: malloc (vg_replace_malloc.c:236) ==2597==by 0x4144AA0: ??? (in /lib/i686/cmov/libc-2.7.so) ==2597==by 0x414539B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so) ==2597==by 0x470AF5B: ??? ==2597==by 0x470D0B4: ??? ==2597==by 0x40EC011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so) ==2597==by 0x40EB996: getpwuid (in /lib/i686/cmov/libc-2.7.so) ==2597==by 0x4035FCB: user_from_uid (in /lib/libproc-3.2.7.so) ==2597==by 0x403735C: ??? (in /lib/libproc-3.2.7.so) ==2597==by 0x4037D7E: readproc (in /lib/libproc-3.2.7.so) ==2597==by 0x8049A8D: ??? (in /bin/ps) ==2597==by 0x804A382: ??? (in /bin/ps) ==2597== ==2597== LEAK SUMMARY: ==2597==definitely lost: 36 bytes in 1 blocks ==2597==indirectly lost: 120 bytes in 10 blocks ==2597== possibly lost: 0 bytes in 0 blocks ==2597==still reachable: 810 bytes in 33 blocks ==2597== suppressed: 0 bytes in 0 blocks ==2597== Reachable blocks (those to which a pointer was found) are not shown. ==2597== To see them, rerun with: --leak-check=full --show-reachable=yes ==2597== 3. ls -latr debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full ls -latr ==2592== HEAP SUMMARY: ==2592== in use at exit: 12,680 bytes in 41 blocks ==2592== total heap usage: 276 allocs, 235 frees, 39,123 bytes allocated ==2592== ==2592== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 29 ==2592==at 0x40221CA: malloc (vg_replace_malloc.c:236) ==2592==by 0x414DAA0: ??? (in /lib/i686/cmov/libc-2.7.so) ==2592==by 0x414E39B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so) ==2592==by 0x4714F5B: ??? ==2592==by 0x47170B4: ??? ==2592==by 0x40F5011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so) ==2592==by 0x40F4996: getpwuid (in /lib/i686/cmov/libc-2.7.so) ==2592==by 0x8053982: ??? (in /bin/ls) ==2592==by 0x804AA7B: ??? (in /bin/ls) ==2592==
Re: Potential memory leaks reported by Valgrind against some frequently used commands
2011/3/1 ximalaya im...@126.com: I notice that, valgrind reports memory leaks against some frequently used commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps -ef, ls -latr, top, etc. For short-running processes that's generally not a problem. -- Olaf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikrvavkxvzjgltmgrqerca7fxii9hdl8mhvp...@mail.gmail.com
Re: Potential memory leaks reported by Valgrind against some frequently used commands
On Tue, Mar 1, 2011 at 19:54, Olaf van der Spek olafvds...@gmail.com wrote: 2011/3/1 ximalaya im...@126.com: I notice that, valgrind reports memory leaks against some frequently used commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps -ef, ls -latr, top, etc. For short-running processes that's generally not a problem. -- Olaf It would be good if we fix them, :) -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktint9f0+ppndptnkcemgiabbxvvwwhnkab9z_...@mail.gmail.com
Re: Potential memory leaks reported by Valgrind against some frequently used commands
01.03.2011 14:56, Aron Xu wrote: On Tue, Mar 1, 2011 at 19:54, Olaf van der Spek olafvds...@gmail.com wrote: 2011/3/1 ximalaya im...@126.com: I notice that, valgrind reports memory leaks against some frequently used commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps -ef, ls -latr, top, etc. For short-running processes that's generally not a problem. It would be good if we fix them, :) There are at least two kinds of memory leaks which may be present and reported here. One is a single memory buffer allocated (and may be reallocated) for some one-time task and not freed. And another may be a missing free for every object a program iterates - like in case of ls, a memleak of an object for every file it lists. First kinds of memory leaks are definitely _not_ worth to fix, because if we'll exit right away anyway, kernel will free all our memory in one go after process termination, and by using free() we just wating CPU time and gains nothing at all. But second kind of leaks is definitely worth to fix, for obvious reason: tools like ls(1) should not grow their memory without bounds. But I suspect there are only kind-1 leaks you found, at least the ones which are reported are all of this sort. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6ce0c0.7050...@msgid.tls.msk.ru
Potential memory leaks reported by Valgrind against some frequently used commands
Hi, As you may have known, valgrind is a powerful and easy to use tool that can be used to detect many memory management issues on Linux. Details regarding valgrind can be seen here, http://valgrind.org I notice that, valgrind reports memory leaks against some frequently used commands of Debian 5.0.7 and 4.0. Don't have a chance to try later releases, but I think the problem may still be there. These commands include netstat, ps -ef, ls -latr, top, etc. I post the reports here, hope someone can look into this issue and get it resolved(pay attention to function calls in libc-2.7.so). Environment == OS: debian 5.07 debian:~# uname -a Linux debian 2.6.26-2-686 #1 SMP Sat Nov 20 23:06:30 UTC 2010 i686 GNU/Linux debian:/lib/i686/cmov# gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) debian:/lib/i686/cmov# /usr/local/valgrind/bin/valgrind --version valgrind-3.6.1 Valgrind reports 1. netstat debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full netstat ==2591== ==2591== HEAP SUMMARY: ==2591== in use at exit: 15,122 bytes in 1,125 blocks ==2591== total heap usage: 1,367 allocs, 242 frees, 42,343 bytes allocated ==2591== ==2591== 66 (48 direct, 18 indirect) bytes in 4 blocks are definitely lost in loss record 6 of 11 ==2591==at 0x40221CA: malloc (vg_replace_malloc.c:236) ==2591==by 0x804FE96: ??? (in /bin/netstat) ==2591==by 0x8049E1A: ??? (in /bin/netstat) ==2591==by 0x804A3DC: ??? (in /bin/netstat) ==2591==by 0x804CD14: ??? (in /bin/netstat) ==2591==by 0x4047454: (below main) (in /lib/i686/cmov/libc-2.7.so) ==2591== ==2591== LEAK SUMMARY: ==2591==definitely lost: 48 bytes in 4 blocks ==2591==indirectly lost: 18 bytes in 4 blocks ==2591== possibly lost: 0 bytes in 0 blocks ==2591==still reachable: 15,056 bytes in 1,117 blocks ==2591== suppressed: 0 bytes in 0 blocks ==2591== Reachable blocks (those to which a pointer was found) are not shown. ==2591== To see them, rerun with: --leak-check=full --show-reachable=yes ==2591== ==2591== For counts of detected and suppressed errors, rerun with: -v 2. ps -ef debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full ps -ef ==2597== ==2597== HEAP SUMMARY: ==2597== in use at exit: 966 bytes in 44 blocks ==2597== total heap usage: 390 allocs, 346 frees, 20,255 bytes allocated ==2597== ==2597== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 28 of 30 ==2597==at 0x40221CA: malloc (vg_replace_malloc.c:236) ==2597==by 0x4144AA0: ??? (in /lib/i686/cmov/libc-2.7.so) ==2597==by 0x414539B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so) ==2597==by 0x470AF5B: ??? ==2597==by 0x470D0B4: ??? ==2597==by 0x40EC011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so) ==2597==by 0x40EB996: getpwuid (in /lib/i686/cmov/libc-2.7.so) ==2597==by 0x4035FCB: user_from_uid (in /lib/libproc-3.2.7.so) ==2597==by 0x403735C: ??? (in /lib/libproc-3.2.7.so) ==2597==by 0x4037D7E: readproc (in /lib/libproc-3.2.7.so) ==2597==by 0x8049A8D: ??? (in /bin/ps) ==2597==by 0x804A382: ??? (in /bin/ps) ==2597== ==2597== LEAK SUMMARY: ==2597==definitely lost: 36 bytes in 1 blocks ==2597==indirectly lost: 120 bytes in 10 blocks ==2597== possibly lost: 0 bytes in 0 blocks ==2597==still reachable: 810 bytes in 33 blocks ==2597== suppressed: 0 bytes in 0 blocks ==2597== Reachable blocks (those to which a pointer was found) are not shown. ==2597== To see them, rerun with: --leak-check=full --show-reachable=yes ==2597== 3. ls -latr debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full ls -latr ==2592== HEAP SUMMARY: ==2592== in use at exit: 12,680 bytes in 41 blocks ==2592== total heap usage: 276 allocs, 235 frees, 39,123 bytes allocated ==2592== ==2592== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 29 ==2592==at 0x40221CA: malloc (vg_replace_malloc.c:236) ==2592==by 0x414DAA0: ??? (in /lib/i686/cmov/libc-2.7.so) ==2592==by 0x414E39B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so) ==2592==by 0x4714F5B: ??? ==2592==by 0x47170B4: ??? ==2592==by 0x40F5011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so) ==2592==by 0x40F4996: getpwuid (in /lib/i686/cmov/libc-2.7.so) ==2592==by
Re:Re:Re: Potential memory leaks reported by Valgrind against some frequently used commands
Agree with you all. For process that will terminate anyway, this may be not a problem really. While if there is any problem with the underlying libraries, it is worth looking into... At 2011-03-01 20:19:39，ximalaya im...@126.com wrote: Hi all, It's a surprise that you replied this email so quickly. Thanks for your timely comments! Several days ago, I ever posted todebian-u...@lists.debian.org, but got no response. BTW, I ever tried on Redhat Linux 9, no such problem. Thanks, Xmly At 2011-03-01 20:04:16，Michael Tokarev m...@tls.msk.ru wrote: 01.03.2011 14:56, Aron Xu wrote: On Tue, Mar 1, 2011 at 19:54, Olaf van der Spek olafvds...@gmail.com wrote: 2011/3/1 ximalaya im...@126.com: I notice that, valgrind reports memory leaks against some frequently used commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps -ef, ls -latr, top, etc. For short-running processes that's generally not a problem. It would be good if we fix them, :) There are at least two kinds of memory leaks which may be present and reported here. One is a single memory buffer allocated (and may be reallocated) for some one-time task and not freed. And another may be a missing free for every object a program iterates - like in case of ls, a memleak of an object for every file it lists. First kinds of memory leaks are definitely _not_ worth to fix, because if we'll exit right away anyway, kernel will free all our memory in one go after process termination, and by using free() we just wating CPU time and gains nothing at all. But second kind of leaks is definitely worth to fix, for obvious reason: tools like ls(1) should not grow their memory without bounds. But I suspect there are only kind-1 leaks you found, at least the ones which are reported are all of this sort. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6ce0c0.7050...@msgid.tls.msk.ru
Re:Re: Potential memory leaks reported by Valgrind against some frequently used commands
Hi all, It's a surprise that you replied this email so quickly. Thanks for your timely comments! Several days ago, I ever posted to debian-u...@lists.debian.org, but got no response. BTW, I ever tried on Redhat Linux 9, no such problem. Thanks, Xmly At 2011-03-01 20:04:16，Michael Tokarev m...@tls.msk.ru wrote: 01.03.2011 14:56, Aron Xu wrote: On Tue, Mar 1, 2011 at 19:54, Olaf van der Spek olafvds...@gmail.com wrote: 2011/3/1 ximalaya im...@126.com: I notice that, valgrind reports memory leaks against some frequently used commands on Debian 6.0, 5.0.7 and 4.0. These commands include netstat, ps -ef, ls -latr, top, etc. For short-running processes that's generally not a problem. It would be good if we fix them, :) There are at least two kinds of memory leaks which may be present and reported here. One is a single memory buffer allocated (and may be reallocated) for some one-time task and not freed. And another may be a missing free for every object a program iterates - like in case of ls, a memleak of an object for every file it lists. First kinds of memory leaks are definitely _not_ worth to fix, because if we'll exit right away anyway, kernel will free all our memory in one go after process termination, and by using free() we just wating CPU time and gains nothing at all. But second kind of leaks is definitely worth to fix, for obvious reason: tools like ls(1) should not grow their memory without bounds. But I suspect there are only kind-1 leaks you found, at least the ones which are reported are all of this sort. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6ce0c0.7050...@msgid.tls.msk.ru
Re: Potential memory leaks reported by Valgrind against some frequently used commands
On 03/01/2011 06:19 AM, ximalaya wrote: Hi all, [snip] BTW, I ever tried on Redhat Linux 9, no such problem. This is the interesting part. Is RH keeping their patches, or are upstream and other distros just not determining them worthwhile? -- I prefer banana-flavored energy bars made from tofu. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d6dadb2.4010...@cox.net
Re: Potential memory leaks reported by Valgrind against some frequently used commands
On Tue, Mar 01, 2011 at 08:38:42PM -0600, Ron Johnson wrote: On 03/01/2011 06:19 AM, ximalaya wrote: BTW, I ever tried on Redhat Linux 9, no such problem. This is the interesting part. Is RH keeping their patches, or are upstream and other distros just not determining them worthwhile? given that RH9 is like what, 10 years old, i'd think that it's just as likely that the utilities just weren't leaky at the time. sean -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110302064339.ga27...@cobija.connexer.com
Re: Potential memory leaks reported by Valgrind against some frequently used commands
Hi! On Wednesday 02 March 2011 03.38:42 Ron Johnson wrote: On 03/01/2011 06:19 AM, ximalaya wrote: Hi all, [snip] BTW, I ever tried on Redhat Linux 9, no such problem. This is the interesting part. Is RH keeping their patches, or are upstream and other distros just not determining them worthwhile? Or is it an eglibc libc issue? (Not sure what libc RH is using.) -- vbi -- Vertrauen ist gut. Anwalt ist saugeil. signature.asc Description: This is a digitally signed message part.
