This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 136630 - memory leak in /usr/bin/watch
memory leak in /usr/bin/watch
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Karel Zak
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2004-12-20 15:56:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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):
procps-2.0.17-10

How reproducible:
Always

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

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"
3585348

... 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.

http://rhn.redhat.com/errata/RHBA-2004-550.html

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