Bug 151597 - /proc/<PID>/status shows unreasonable VmLib value
/proc/<PID>/status shows unreasonable VmLib value
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Baron
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-03-20 11:30 EST by David Tonhofer
Modified: 2013-03-06 00:58 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-07 01:39:16 EDT
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 David Tonhofer 2005-03-20 11:30:41 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910

Description of problem:
The machine is a two-processor EM64T Xeon with 2.6.9-5.0.3.ELsmp

The display for 'VmLib' (VM size of libraries)
in /proc/<PID>/status seems to be a bit on the
large side for a MySQL process (actually the thread group leader if I
understand correctly). This is the only 'status' that has this problem
all the other show values that are reasonable:

Name:   mysqld
State:  S (sleeping)
SleepAVG:       98%
Tgid:   8123
Pid:    8123
PPid:   8095
TracerPid:      0
Uid:    101     101     101     101
Gid:    101     101     101     101
FDSize: 256
Groups: 101
VmSize:   745184 kB
VmLck:         0 kB
VmRSS:    334584 kB
VmData:   716632 kB
VmStk:        32 kB
VmExe:      3646 kB
VmLib:  18446744073708325478 kB  <---- 0xFFFF'FFFF'FFED'4A66
StaBrk: 008b1000 kB
Brk:    0157a000 kB
StaStk: 7fbfffefd0 kB
Threads:        71
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000085007
SigIgn: 0000000000001006
SigCgt: 00000001800064e9
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

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

How reproducible:
Didn't try

Steps to Reproduce:

Actual Results:  VmLib shows unreasonable value.

Expected Results:  VmLib should show something reasonable.

Additional info:
Comment 2 Rik van Riel 2008-05-06 13:41:11 EDT
That looks like a negative value to me, with the statistic somehow underflowing.

From task_mem() in fs/proc/proc_mmu.c:

char *task_mem(struct mm_struct *mm, char *buffer)
        unsigned long data, text, lib;

        data = mm->total_vm - mm->shared_vm - mm->stack_vm;
        text = (mm->end_code - mm->start_code) >> 10;
        lib = (mm->exec_vm << (PAGE_SHIFT-10)) - text;

It appears that lib is generated by subtracting text from exec_vm.

In __vm_stat_account() in mm/mmap.c:

        if (flags & VM_EXEC)
                mm->exec_vm += pages;

However, for backwards compatibility, the i386 architecture emulation code
forces exec rights on a VM that is mapped with just VM_READ.  That means that
the text section could end up larger than what is counted in the exec_vm statistic.

This results in the statistics being printed wrong for 32 bit apps that do not
use PROT_EXEC in their mmap calls, but should otherwise be harmless.
Comment 3 David Tonhofer 2008-05-06 15:58:32 EDT
Hi, original poster here.

The error is certainly harmless we never had a problem with the large values.
Problem still occurs on the latest update of RH4.

Note that the MySQL process shown above is a 64-bit executable (ELF 64-bit LSB
executable, AMD x86-64) compiled on the 64-bit machine, so this is not
restricted to 32-bit processes.

Comment 7 Joseph W. Breu 2009-02-16 11:37:09 EST
Can you confirm that the RAM used/free reported by 'free' is mis-reported as well?

In our case, I have a AMD 64bit box with 32GB of RAM running memcached and mysqld.  Those processes combined use <6GB of RAM, but the OS is reported >30GB utilized.

/proc/<mysqld pid>/status reports VmLib for MySQL is:

VmLib:	18446744073709543776 kB

Comment 8 David Tonhofer 2009-02-16 16:32:55 EST

I just checked that this occurs on 2.6.9-78.0.5.ELsmp (RH 4.7) by running

LIST=`find /proc -name status`
for I in $LIST; do echo $I; grep VmLib $I; done


The fact that the OS says that 30GB are utilized should be normal - Linux uses the RAM as cache as far as possible.

"free" then shows something near 0, like this:

             total       used       free     shared    buffers     cached
Mem:       5071004    4875856     195148          0     740968    2266892
-/+ buffers/cache:    1867996    3203008
Swap:      3080184        180    3080004

Try my script at http://misato.m-plify.net/memory to print a nice tree representation of the memory used (hopefully correct).
Comment 9 Joseph W. Breu 2009-02-17 12:27:47 EST
Here's what I get when running the memory script.  Something is overflowing here...

Total physical memory available
|--Swap memory                     1077469184 
|  |--Free:                        1077239808 
|  `--Used:                            229376 
`--Dynamic memory:                 33730404352 
   |||--Free:                       161181696 
   ||`--Used:                      33569222656 
   ||   |--Kernel slab:             706445312 
   ||   |  `--Page tables:           17686528 
   ||   `--Non-kernel:             32862777344 
   ||      |--Caching:             1278234624 
   ||      |  |--Buffer cache:      572407808 
   ||      |  |--Page cache:        705826816 
   ||      |  |  |--Mapped:        6656565248 
   ||      |  |  |  |--Dirty:          143360 
   ||      |  |  |  |--Writeback:           0 
   ||      |  |  |  `--Clean:      6656421888 
   ||      |  |  `--Copied:        -5950738432 
   ||      |  `--Swapcached:                0 
   ||      `--User processes:      31584542720 
   ||          `--Sum RSS:         6790004736 
   ||--Inactive pages:             1548386304 
   ||--Active pages:               31273738240 
   |`--Other pages:                 908279808 
   |--Low memory:                  33730404352 
   |  |--Free:                      161181696 
   |  `--Used:                     33569222656 
   `--High memory:                          0 
      |--Free:                              0 
      `--Used:                              0
Comment 10 David Tonhofer 2009-02-17 14:03:55 EST
Ok, don't worry about the overflow; I must have interpreted "copied" wrongly. 

What is of interest to you is -- why the large difference between 

         `--User processes:      31584542720 
              `--Sum RSS:         6790004736 

Unfortunately I don't know. But as this has nothing to do with this bug, the discussion should be taken to the General Red Hat Discussion List [http://www.redhat.com/mailman/listinfo] or maybe the Linux kernel list [http://www.kernel.org/pub/linux/docs/lkml/]. 

Best regards,


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