'ps' incorrectly reports virutal memory usage

[Qwanve]

Describe the bug
The 'ps' command reports virtual memory usage many times over reasonable numbers.

To Reproduce
Steps to reproduce the behavior:

1. Run some program. I've used 'yes > /dev/null' to demonstrate
2. Run ps

Expected behavior
I expect the built in 'ps' command to provide information similar to the external 'ps' command

Screenshots
^ps -af

ps | where name == "yes"

Configuration (please complete the following information):

Run version | pivot and paste the output to show OS, features, etc.

> version | pivot
────┬────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────
 #  │      Column0       │                                                 Column1
────┼────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────
  0 │ version            │ 0.26.0
  1 │ branch             │ main
  2 │ short_commit       │ fb184612
  3 │ commit_hash        │ fb1846120d54f31db687eb4f9c88a57534a03a3c
  4 │ commit_date        │ 2021-02-03 06:19:38
  5 │ build_os           │ linux-x86_64
  6 │ rust_version       │ rustc 1.49.0 (e1884a8e3 2020-12-29)
  7 │ rust_channel       │ stable-x86_64-unknown-linux-gnu (default)
  8 │ cargo_version      │ cargo 1.49.0 (d00d64df9 2020-12-05)
  9 │ pkg_version        │ 0.26.0
 10 │ build_time         │ 2021-02-03 21:43:28
 11 │ build_rust_channel │ release
 12 │ features           │ clipboard-cli, ctrlc, default, directories, dirs, ichwh, ptree, rustyline, term, trash, uuid, which, zip
────┴────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────

[fdncred]

I looked at the sysinfo code and they're dividing by 1000 and we're multiplying by 1000 so we get bytes. But, I still agree that it seems to be way off i.e. a factor of 1000.

This is what mine looks like in Windows. My system doesn't have terabytes of virtual memory.

╭─────┬───────┬────────────────────────────────────────────────────────┬────────┬────────┬──────────┬──────────╮
│  #  │ pid   │ name                                                   │ status │ cpu    │ mem      │ virtual  │
├─────┼───────┼────────────────────────────────────────────────────────┼────────┼────────┼──────────┼──────────┤
│   0 │  5960 │ mfemms.exe                                             │ Run    │ 0.0000 │  11.3 MB │   4.4 GB │
│   1 │  9728 │ taskhostw.exe                                          │ Run    │ 0.0000 │  16.6 MB │   2.2 TB │
│   2 │ 21004 │ ShellExperienceHost.exe                                │ Run    │ 0.0000 │ 114.4 MB │   2.2 TB │
│   3 │ 27636 │ explorer.exe                                           │ Run    │ 0.0000 │  67.2 MB │   2.2 TB │
│   4 │ 13900 │ TGitCache.exe                                          │ Run    │ 0.0000 │  12.6 MB │   4.5 GB │
│   5 │ 24752 │ dllhost.exe                                            │ Run    │ 0.0000 │  15.8 MB │   2.2 TB │
│   6 │  2132 │ svchost.exe                                            │ Run    │ 0.0000 │   4.9 MB │   2.2 TB │
│   7 │  7576 │ svchost.exe                                            │ Run    │ 0.0000 │  33.3 MB │   2.2 TB │
│   8 │ 15120 │ IGCCTray.exe                                           │ Run    │ 0.0000 │  23.0 MB │   5.1 GB │

[fdncred]

Something is going on somewhere in nushell.

When I run nu's ps i get this

358 │ 14968 │ vmware-remotemks.exe                            │ Run    │ 0.0000 │   449,245,000 │ 2,256,402,612,000

when i run the sysinfo example program i get

pid: 14968,
name: "vmware-remotemks.exe",
memory usage: 449245, = 449,245,000 since sysinfo reports in KB
virtual memory usage: 844783 = 844,783,000 since sysinfo reports in KB

[fdncred]

I added a trace to return what process.virtual_memory() is returning.

TRACE nu::trace_stream::internal     > input = (pid=14968
 name="vmware-remotemks.exe"
 status="Run"
 cpu=0.3843336105346680
 mem=BigInt { sign: Plus, data: BigUint { data: [70340000] } }(filesize)
 virtual=BigInt { sign: Plus, data: BigUint { data: [2256402612] } }(filesize))

This seems to indicate that sysinfo is reporting wrong?

[sophiajt]

Can you try it with the latest main? I just landed #3007 which hopefully will improve it

[sophiajt]

Hmm, while Windows seems okay, I'm still seeing large values in Linux.

[fdncred]

On Windows it's looking good @jonathandturner. I'm building in WSL2 now to see if I see anything odd in Linux.

[fdncred]

Something is going on in linux as well I think. mem looks ok but virutal not so much.

ps -l | where pid == 51
╭───┬─────┬──────┬────────┬────────┬────────────┬───────────────────┬────────┬───────────────┬─────────╮
│ # │ pid │ name │ status │ cpu    │ mem        │ virtual           │ parent │ exe           │ command │
├───┼─────┼──────┼────────┼────────┼────────────┼───────────────────┼────────┼───────────────┼─────────┤
│ 0 │  51 │ fish │ Sleep  │ 0.0000 │ 12,040,000 │ 5,838,651,392,000 │      9 │ /usr/bin/fish │ fish    │
╰───┴─────┴──────┴────────┴────────┴────────────┴───────────────────┴────────┴───────────────┴─────────╯

This is what virtual should be as per the man proc.

cat /proc/51/stat | cut -d" " -f23
1,459,662,848

5.8TB vs 1.4GB

I've posted the same info to the sysinfo issue as well.

---

Update - I think I may see the problem in Linux.

entry.virtual_memory = u64::from_str(parts[22]).unwrap_or(0) * page_size_kb; 

https://github.com/GuillaumeGomez/sysinfo/blob/a3099e08735f752009a6ac7a9f709fba4c855344/src/linux/system.rs#L655

According to man proc

              (23) vsize  %lu
                     Virtual memory size in bytes.

It's reporting in bytes and then sysinfo is multiplying page_size_kb.

[fdncred]

Submitted PR to fix linux virtual memory.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions]

This issue has been marked stale for more than 10 days without activity. Closing this issue, but if you find that the issue is still valid, please reopen.