Bug 136630 - memory leak in /usr/bin/watch
memory leak in /usr/bin/watch
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Karel Zak
Depends On:
  Show dependency treegraph
Reported: 2004-10-21 07:07 EDT by Ville Herva
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-20 15:56:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ville Herva 2004-10-21 07:07:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3)
Gecko/20040913 Firefox/0.10.1

Description of problem:
I left command
watch 'top -b -n1;echo;df -mT;echo;egrep "(dentry|inode)"
/proc/slabinfo;echo;ls /data/burn|wc -l'

running for a couple of hours and it swelled to 922 mega bytes.

 4117 root      16   0  922M 922M   664 S     0.0 30.6   0:17   0 watch

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. watch 'top -b -n1;echo;df -mT;echo;egrep "(dentry|inode)"
/proc/slabinfo;echo;ls /data/burn|wc -l'

Actual Results:  watch swelled to 922MB

Expected Results:  No memory leak

Additional info:
Comment 1 Ville Herva 2004-10-21 07:08:31 EDT
Haven't seen this sort of behaviour on other distros (though I haven't
tried the exact same test case). Possibly fixed in upstream?
Comment 2 Ville Herva 2004-10-28 06:44:18 EDT
OTOH, I have absolutely no idea where top(1) gets these values; top show:

 5065 root      15   0 3502M 3.4G   664 S     0.0 116.3   0:57   3 watch

but statm only shows

[1]root@denali:/proc/5065>cat statm
896338 896337 166 16303 16307 863727 55

Is 3.4GB even possible (x86, CONFIG_3GB afaict) - shouldn't user space
be limited to 3GB??
Comment 3 Karel Zak 2004-11-10 05:20:41 EST
In the file /proc/<pid>/statm are number of pages (!= bytes). For
conversion to bytes:
$ python -c "print 896337 << 2"

... and it's 3.5 GB. It means the "top" is right in this case.

It's maybe same kernel problem like in bug report #137927. 

Ville, which version of kernel are you using? (uname -a)
Comment 4 Ville Herva 2004-11-10 06:10:45 EST
Well, the watch swelled way up to almost 12GB and a zsh swelled up to 
1.5GB according to top before I had to reboot (for other reasons). 
(Obviously, they weren't that big for real.)

I've seen this with all recent RHEL3ESu3 update kernels, at least 
with 2.4.21-20.ELsmp, 2.4.21-22.prune_icachefix.ELsmp (see bug 
#132639) and (I think) and 2.4.21-22. Now I'm running 2.4.21-15.
Comment 5 Ville Herva 2004-11-12 02:47:23 EST
It seems 2.4.21-15 doesn't show this problem. Just the newer ones.
Comment 6 Ville Herva 2004-11-12 06:30:06 EST

*** This bug has been marked as a duplicate of 137927 ***
Comment 7 Ernie Petrides 2004-12-03 19:46:33 EST
This turned out to be a kernel bug, which has been fixed in RHEL3 U4
(as of kernel version 2.4.21-27.EL, built a couple of days ago).
Comment 8 Ernie Petrides 2004-12-09 21:55:11 EST
The fix for this problem has also been committed to the RHEL3 U5
patch pool this evening (in kernel version 2.4.21-27.3.EL).
Comment 9 John Flanagan 2004-12-20 15:56:47 EST
An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.