Bug 136630
| Summary: | memory leak in /usr/bin/watch | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Ville Herva <v> |
| Component: | kernel | Assignee: | Karel Zak <kzak> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | anderson, petrides, riel |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-12-20 20:56:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Haven't seen this sort of behaviour on other distros (though I haven't tried the exact same test case). Possibly fixed in upstream? 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?? 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) 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. It seems 2.4.21-15 doesn't show this problem. Just the newer ones. *** This bug has been marked as a duplicate of 137927 *** 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). 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). 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 |
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: