Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Potential memory leaks reported by Valgrind against some frequently used commands (http://www.linux-archive.org/debian-development/495671-potential-memory-leaks-reported-valgrind-against-some-frequently-used-commands.html)

ximalaya 03-01-2011 10:42 AM

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 --witho
ut-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== F
or 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/loc
al/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==*** by 0x804B71A: ??? (in /bin/ls)
==2592==*** by 0x804E006: ??? (in /bin/ls)
==2592==*** by 0x804F32E: ??? (in /bin/ls)
==2592==
==2592== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 28 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 0x4713F0B: ???
==2592==*** by 0x4714CEC: ???
==2592==*** by 0x40F3A41: getgrgid_r (in /lib/i686/cmov/libc-2.7.so)
==2592==*** by 0x40F3216: getgrgid (in /lib/i686/cmov/libc-2.7.so)
==2592==*** by 0x8053812: ??? (in /bin/ls)
==2592==*** by 0x804BB2C: ??? (in /bin/ls)
==2592==**&nbs
p; by 0x804E006: ??? (in /bin/ls)
==2592==*** by 0x804F32E: ??? (in /bin/ls)
==2592==*** by 0x4070454: (below main) (in /lib/i686/cmov/libc-2.7.so)
==2592==
==2592== LEAK SUMMARY:
==2592==*** definitely lost: 72 bytes in 2 blocks
==2592==*** indirectly lost: 240 bytes in 20 blocks
==2592==***** possibly lost: 0 bytes in 0 blocks
==2592==*** still reachable: 12,368 bytes in 19 blocks
==2592==******** suppressed: 0 bytes in 0 blocks
==2592== Reachable blocks (those to which a pointer was found) are not shown.
==2592== To see them, rerun with: --leak-check=full --show-reachable=yes
==2592==

4. top
debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full top
==2593== HEAP SUMMARY:
==2593==**** in use at exit: 50,612 bytes in 96 blocks
==2593==** total
heap usage: 238 allocs, 142 frees, 72,774 bytes allocated
==2593==
==2593== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 17 of 29
==2593==*** at 0x40221CA: malloc (vg_replace_malloc.c:236)
==2593==*** by 0x4176AA0: ??? (in /lib/i686/cmov/libc-2.7.so)
==2593==*** by 0x417739B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so)
==2593==*** by 0x45E4F5B: ???
==2593==*** by 0x45E70B4: ???
==2593==*** by 0x411E011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so)
==2593==*** by 0x411D996: getpwuid (in /lib/i686/cmov/libc-2.7.so)
==2593==*** by 0x4035FCB: user_from_uid (in /lib/libproc-3.2.7.so)
==2593==*** by 0x403735C: ??? (in /lib/libproc-3.2.7.so)
==2593==*** by 0x4037D7E: readproc (in /lib/libproc-3.2.7.so)
==2593==*** by 0x804C633: ??? (in
/usr/bin/top)
==2593==*** by 0x8050FC0: ??? (in /usr/bin/top)
==2593==
==2593== LEAK SUMMARY:
==2593==*** definitely lost: 36 bytes in 1 blocks
==2593==*** indirectly lost: 120 bytes in 10 blocks
==2593==***** possibly lost: 0 bytes in 0 blocks
==2593==*** still reachable: 50,456 bytes in 85 blocks
==2593==******** suppressed: 0 bytes in 0 blocks
==2593== Reachable blocks (those to which a pointer was found) are not shown.
==2593== To see them, rerun with: --leak-check=full --show-reachable=yes

Thanks and Best Regards,
Xmly

ximalaya 03-01-2011 10:50 AM

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=/us
r/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
de
bian:~# /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==*** by 0x804B71A: ??? (in /bin/ls)
=
=2592==*** by 0x804E006: ??? (in /bin/ls)
==2592==*** by 0x804F32E: ??? (in /bin/ls)
==2592==
==2592== 156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 28 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 0x4713F0B: ???
==2592==*** by 0x4714CEC: ???
==2592==*** by 0x40F3A41: getgrgid_r (in /lib/i686/cmov/libc-2.7.so)
==2592==*** by 0x40F3216: getgrgid (in /lib/i686/cmov/libc-2.7.so)
==2592==*** by 0x8053812: ??? (in /bin/ls)
==2592==*** by 0x804BB2C: ??? (in /bin/ls)
==2592==*** by 0x804E006: ??? (in /bin/ls)
==2592==*** by 0x804F32E: ???
(in /bin/ls)
==2592==*** by 0x4070454: (below main) (in /lib/i686/cmov/libc-2.7.so)
==2592==
==2592== LEAK SUMMARY:
==2592==*** definitely lost: 72 bytes in 2 blocks
==2592==*** indirectly lost: 240 bytes in 20 blocks
==2592==***** possibly lost: 0 bytes in 0 blocks
==2592==*** still reachable: 12,368 bytes in 19 blocks
==2592==******** suppressed: 0 bytes in 0 blocks
==2592== Reachable blocks (those to which a pointer was found) are not shown.
==2592== To see them, rerun with: --leak-check=full --show-reachable=yes
==2592==

4. top
debian:~# /usr/local/valgrind/bin/valgrind --leak-check=full top
==2593== HEAP SUMMARY:
==2593==**** in use at exit: 50,612 bytes in 96 blocks
==2593==** total heap usage: 238 allocs, 142 frees, 72,774 bytes allocated
==2593==
==2593==
156 (36 direct, 120 indirect) bytes in 1 blocks are definitely lost in loss record 17 of 29
==2593==*** at 0x40221CA: malloc (vg_replace_malloc.c:236)
==2593==*** by 0x4176AA0: ??? (in /lib/i686/cmov/libc-2.7.so)
==2593==*** by 0x417739B: __nss_database_lookup (in /lib/i686/cmov/libc-2.7.so)
==2593==*** by 0x45E4F5B: ???
==2593==*** by 0x45E70B4: ???
==2593==*** by 0x411E011: getpwuid_r (in /lib/i686/cmov/libc-2.7.so)
==2593==*** by 0x411D996: getpwuid (in /lib/i686/cmov/libc-2.7.so)
==2593==*** by 0x4035FCB: user_from_uid (in /lib/libproc-3.2.7.so)
==2593==*** by 0x403735C: ??? (in /lib/libproc-3.2.7.so)
==2593==*** by 0x4037D7E: readproc (in /lib/libproc-3.2.7.so)
==2593==*** by 0x804C633: ??? (in /usr/bin/top)
==2593==*** by 0x8050FC0: ??? (in /usr/bin/top)==2593==
==2593== LEAK SUMMARY:
==2593==*** definitely lost: 36 bytes in 1 blocks
==2593==*** indirectly lost: 120 bytes in 10 blocks
==2593==***** possibly lost: 0 bytes in 0 blocks
==2593==*** still reachable: 50,456 bytes in 85 blocks
==2593==******** suppressed: 0 bytes in 0 blocks
==2593== Reachable blocks (those to which a pointer was found) are not shown.
==2593== To see them, rerun with: --leak-check=full --show-reachable=yes

Thanks and Best Regards,
Xmly

Olaf van der Spek 03-01-2011 10:54 AM

Potential memory leaks reported by Valgrind against some frequently used commands
 
2011/3/1 ximalaya <ims3g@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTikRVAVkXvzjgLtmGrQeRcA7fxii9HdL8mhvpSZy@mail .gmail.com">http://lists.debian.org/AANLkTikRVAVkXvzjgLtmGrQeRcA7fxii9HdL8mhvpSZy@mail .gmail.com

Aron Xu 03-01-2011 10:56 AM

Potential memory leaks reported by Valgrind against some frequently used commands
 
On Tue, Mar 1, 2011 at 19:54, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> 2011/3/1 ximalaya <ims3g@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: AANLkTinT9f0+PpnDptNkcEMGiABBxvVWwHnKaB9Z_e49@mail .gmail.com">http://lists.debian.org/AANLkTinT9f0+PpnDptNkcEMGiABBxvVWwHnKaB9Z_e49@mail .gmail.com

Michael Tokarev 03-01-2011 11:04 AM

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 <olafvdspek@gmail.com> wrote:
>> 2011/3/1 ximalaya <ims3g@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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D6CE0C0.7050803@msgid.tls.msk.ru">http://lists.debian.org/4D6CE0C0.7050803@msgid.tls.msk.ru

ximalaya 03-01-2011 11:19 AM

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-user@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"┬*<mjt@tls.msk.ru >┬*wrote:

>01.03.2011┬*14:56,┬*Aron┬*Xu┬*wrote:
>>┬*On┬*Tue,┬*Mar┬*1,┬*2011┬*at┬*19:54,┬*Olaf┬*van ┬*der┬*Spek┬*<olafvdspek@gmail.com>┬*wrote:
>>>┬*2011/3/1┬*ximalaya┬*<ims3g@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┬*pro blem.
>
>>┬*
>>┬*It┬*would┬*be┬*good┬*if┬*we┬*fix┬*them,┬*:)
>
>
>There┬*are┬*at┬*least┬*two┬*kinds┬*of┬*"memory┬*l eaks"┬*which┬*may┬*be┬*present
>and┬*reported┬*here.┬*┬*One┬*is┬*a┬*single┬*memor y┬*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┬*fo r┬*every┬*file┬*it┬*lists.
>
>First┬*kinds┬*of┬*memory┬*"leaks"┬*are┬*definitel y┬*_not_┬*worth┬*to┬*fix,
>because┬*if┬*we'll┬*exit┬*right┬*away┬*anyway,┬*k ernel┬*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┬*wor th┬*to┬*fix,┬*for┬*obvious
>reason:┬*tools┬*like┬*ls(1)┬*should┬*not┬*grow┬*t heir┬*memory┬*without
>bounds.
>
>But┬*I┬*suspect┬*there┬*are┬*only┬*kind-1┬*"leaks"┬*you┬*found,┬*at┬*least
>the┬*ones┬*which┬*are┬*reported┬*are┬*all┬*of┬*th is┬*sort.
>
>Thanks!
>
>/mjt
>
>
>--┬*
>To┬*UNSUBSCRIBE,┬*email┬*to┬*debian-devel-REQUEST@lists.debian.org
>with┬*a┬*subject┬*of┬*"unsubscribe".┬*Trouble?┬*C ontact┬*listmaster@lists.debian.org
>Archive:┬*http://lists.debian.org/4D6CE0C0.7050803@msgid.tls.msk.ru
>

ximalaya 03-01-2011 11:43 AM

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┬*<ims3g@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 to debian-user@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"┬*<mjt@tls.msk.ru >┬*wrote:

>01.03.2011┬*14:56,┬*Aron┬*Xu┬*wrote:
>>┬*On┬*Tue,┬*Mar┬*1,┬*2011┬*at┬*19:54,┬*Olaf┬*van ┬*der┬*Spek┬*<olafvdspek@gmail.com>┬*wrote:
>>>┬*2011/3/1┬*ximalaya┬*<ims3g@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┬*pro blem.
>
>>┬*
>>┬*It┬*would┬*be┬*good┬*if┬*we┬*fix┬*them,┬*:)
>
>
>There┬*are┬*at┬*least┬*two┬*kinds┬*of┬*"memory┬*l eaks"┬*which┬*may┬*be┬*present
>and┬*reported┬*here.┬*┬*One┬*is┬*a┬*single┬*memor y┬*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┬*fo r┬*every┬*file┬*it┬*lists.
>
>First┬*kinds┬*of┬*memory┬*"leaks"┬*are┬*definitel y┬*_not_┬*worth┬*to┬*fix,
>because┬*if┬*we'll┬*exit┬*right┬*away┬*anyway,┬*k ernel┬*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┬*wor th┬*to┬*fix,┬*for┬*obvious
>reason:┬*tools┬*like┬*ls(1)┬*should┬*not┬*grow┬*t heir┬*memory┬*without
>bounds.
>
>But┬*I┬*suspect┬*there┬*are┬*only┬*kind-1┬*"leaks"┬*you┬*found,┬*at┬*least
>the┬*ones┬*which┬*are┬*reported┬*are┬*all┬*of┬*th is┬*sort.
>
>Thanks!
>
>/mjt
>
>
>--┬*
>To┬*UNSUBSCRIBE,┬*email┬*to┬*debian-devel-REQUEST@lists.debian.org
>with┬*a┬*subject┬*of┬*"unsubscribe".┬*Trouble?┬*C ontact┬*listmaster@lists.debian.org
>Archive:┬*http://lists.debian.org/4D6CE0C0.7050803@msgid.tls.msk.ru
>

Ron Johnson 03-02-2011 01:38 AM

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4D6DADB2.4010802@cox.net">http://lists.debian.org/4D6DADB2.4010802@cox.net

Adrian von Bidder 03-02-2011 05:52 AM

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.

Wouter Verhelst 03-02-2011 08:17 AM

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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110302091754.GK3124@celtic.nixsys.be">http://lists.debian.org/20110302091754.GK3124@celtic.nixsys.be


All times are GMT. The time now is 08:25 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.