Bug 140410 - (IT#54817) 2.1SA: ps sometimes shows a wrong value for VSZ
2.1SA: ps sometimes shows a wrong value for VSZ
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: procps (Show other bugs)
2.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Brian Brock
:
Depends On:
Blocks: 132992
  Show dependency treegraph
 
Reported: 2004-11-22 15:11 EST by Steve Conklin
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-28 11:51:44 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:11:34 EST
*** This bug has been split off bug 140409 ***

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 Steve Conklin 2004-11-22 15:12:55 EST
procps version for 2.1 is currently procps-2.0.7-11.21AS.4
Comment 2 Karel Zak 2004-11-23 05:56:49 EST
I checked code and it seems it's without bugs. If the files are in
/proc it always read data or it fill zeroes to vm_xxx fields. For
processes with 'Z' status (like your "[cat <defunct>]") should be
kernel keep zeroes in the statm file and "VmXXX" should be missing in
the status file.

I think basic question is why ps_readproc() doesn't read statm and
status files. It can happen only if kernel remove information about
process from /proc during time when ps_readproc() read it. But this
function check it by stat().

Please, can you send results of 
  cat /proc/#/status 
  cat /proc/#/statm
for your [cat <defunct>]?

I think I can add small patch that zeroize vm_xxx and other stuff if
file2str() for stat and statm failed.

I'm sure that we want to use vm_size from /proc/#/status in "ps". It's
used long time and it's in all versions (lates too). The "top" uses
vsize from /proc/#/statm only.




Comment 4 John Flanagan 2005-04-28 11:51:44 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-024.html

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