FS#56681 - [procps-ng] top shows impossibly high RAM usage

Attached to Project: Arch Linux
Opened by Richard Neumann (rne) - Monday, 11 December 2017, 15:01 GMT
Last edited by Gaetan Bisson (vesath) - Friday, 15 December 2017, 20:42 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
Today I encountered that running a plain

top

as standard user resulted in displaying an impossibly high RAM usage (see screenshot) while free showed usual RAM usage.

free -m
total used free shared buff/cache available
Mem: 7812 2233 3351 867 2226 4413
Swap: 0 0 0

I restarted top several times while the issue remained.
After a reboot of the machine, the problem is gone now and I am unable to reproduce it.
Before the issue occured I had high memory usage on the machine due to (another bug in?) gnome-builder, which I subsequently killed (SIGTERM).

Additional info:
* procps-ng 3.3.12-1
* No vimrc, aliases or so.

Steps to reproduce:
I was not able to reproduce this issue
   Bildschirmfoto von »2017-12-1... (104.9 KiB)
This task depends upon

Closed by  Gaetan Bisson (vesath)
Friday, 15 December 2017, 20:42 GMT
Reason for closing:  Fixed
Additional comments about closing:  procps-ng-3.3.12-2 in [testing]
Comment by Andrey Vihrov (andreyv) - Monday, 11 December 2017, 20:45 GMT
I can reproduce this on my system too. Although RAM usage by top has long been kind of flaky (e.g., 20.0/8.0 GiB shown).

Probably you want to report this upstream: https://gitlab.com/procps-ng/procps
Comment by Eli Schwartz (eschwartz) - Friday, 15 December 2017, 19:43 GMT
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Architecture (x86_64 → All)
  • Task assigned to Gaetan Bisson (vesath)
So yeah, turns out this was already fixed upstream in https://gitlab.com/procps-ng/procps/issues/64 but there hasn't been a release yet.

(@rne, thanks for messaging me about this, next time you can just file a reopen request though with the link and a request to backport this.)

Loading...