Bug 140409 - RHE3: ps sometimes shows a wrong value for VSZ
RHE3: ps sometimes shows a wrong value for VSZ
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: procps (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Brian Brock
:
Depends On:
Blocks: 132991
  Show dependency treegraph
 
Reported: 2004-11-22 15:10 EST by Steve Conklin
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-19 23:25:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steve Conklin 2004-11-22 15:10:30 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

Description of problem:
From IT#54817:

customer see a wrong value for VSZ in ps output.
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
...
mmsse     1216  0.0  0.0 589505315 0 ?       ZL   04:17   0:00 [cat <defunct>]
...

The wrong value is always 589505315. (= 0x23232323 = "####")
This must be a defect of ps command.The reason why...

ps command initializes a buffer to collect /proc information as '#'  in simple_spew().
ps command gets a /proc information by ps_readproc(), and ps_readproc() gets the values as follows:

   433     if ((file2str(path, "stat", sbuf, sizeof sbuf)) == -1)
   434         goto next_proc;                 /* error reading /proc/#/stat */
   435     stat2proc(sbuf, p);                         /* parse /proc/#/stat */
...
   438         if ((file2str(path, "statm", sbuf, sizeof sbuf)) != -1 )
   439             statm2proc(sbuf, p);                /* ignore statm errors h        ere */
...
   443        if ((file2str(path, "status", sbuf, sizeof sbuf)) != -1 ){
   444            status2proc(sbuf, p, 0 /*FIXME*/);
   445        }
...

stat2proc() gets p->vsize , and status2proc() gets p->vm_size as VSZ value.

Depending on how things go, ps_readproc() does not read the values from /proc/##/statm and /proc/##/status.

However, ps command always shows VSZ value with using vm_size.
   429 static int pr_vsz(void){
   430   return sprintf(outbuf, "%lu", pp->vm_size);
   431 }

Therefore, this problem is caused by ps command's bug.
pr_vsz() should use not vm_size but vsize.

I've checked the latest procps source both RHEL3 and RHEL2.1. But this bug still remains.

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

How reproducible:
Sometimes

Steps to Reproduce:
1. execute ps ux
2.
3.
  

Actual Results:  Sometimes, vsz is incorrect

Additional info:
Comment 1 Karel Zak 2004-12-01 11:32:44 EST
Bugfix will be released in RHEL-3-U5 (>= procps-2.0.17-13.2).
Comment 2 Jason Smith 2005-03-25 13:48:12 EST
Will this U5 update to procps fix other bugs?  I have noticed that top's SIZE
value is wrong, and doesn't agree with VSZ in ps.  Is this related to the same
issue you described above or is it a completely new bug and should I submit a
new bug report?  I noticed this because I have set apache's RLimitMEM Directive
and was trying to figure out why processes started by apache were getting killed
when top showed their total SIZE to be only half what I set the limit to.  Then
I checked ps and discovered that the process VSZ was indeed hitting the limit.

Also, turning on the DSIZE field in top (L) will show negative values in its
column, yet another or maybe a related bug.
Comment 3 Karel Zak 2005-03-25 18:32:27 EST
I tested VSZ vs. SIZE with procps-2.0.17-13.6 (on non-RHEL3 kernel 2.6.5) and it
looks good. It means without bugs. 

man top:
     DSIZE  Data + Stack size. This is broken for ELF processes.
Comment 4 Dennis Gregorovic 2005-05-19 23:25:49 EDT
An advisory 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-2005-156.html

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