Re: Potential memory leaks reported by Valgrind against some frequently used commands

2011-03-02 Thread Wouter Verhelst
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



Re: Potential memory leaks reported by Valgrind against some frequently used commands

2011-03-01 Thread Olaf van der Spek
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

2011-03-01 Thread Aron Xu
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

2011-03-01 Thread Michael Tokarev
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

2011-03-01 Thread Ron Johnson

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

2011-03-01 Thread sean finney
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

2011-03-01 Thread Adrian von Bidder
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.