GNOME Bugzilla – Bug 598207
GNOME System Monitor sometimes doesn't follow the memory usage order even if desired
Last modified: 2012-07-01 00:01:18 UTC
Created attachment 145310 [details] Processes tab: wrong order although sorting by memory usage is set Sorting processes list by memory usage on Processes tab in System Monitor usually works but after a period of time there are sometimes mistakes that can be corrected only by clicking on a Memory tab twice (first click sorts properly, but in reverse order). Screenshot attached. I reported this bug here, too: https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/449191 ProblemType: Bug Architecture: amd64 Date: Mon Oct 12 03:29:55 2009 DistroRelease: Ubuntu 9.10 InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Alpha amd64 (20091008) Package: gnome-system-monitor 2.28.0-0ubuntu1 ProcVersionSignature: Ubuntu 2.6.31-13.44-generic SourcePackage: gnome-system-monitor Uname: Linux 2.6.31-13-generic x86_64
Hello Michal, when the problem occurs, does it disappear on the next refresh ?
It does. Order of elements doesn't change if I don't fix it manually by double-clicking on the Memory column header.
Confirmed here.
@Benoît Dejean Oh, I meant it does NOT disappear on the next refresh, I've read "does it appear", wrongly. :) What other info do You need?
It seems that at least one of problems comes from the fact that if one already has an open Processes tab and suddenly a new process which memory usage cannot be determined (thus marked N/A) it shows at the top, over most memory-consuming programs. When a new process comes up, it goes over this N/A process in this way being upper than most consuming processes.
Reopening as the requested information has been provided.
We have improved the sorting mechanism for numeric columns in the 3.3.4 release. Could anyone please try if this issue still exists?
[Adding missing "QA Contact" entry so system monitor bug report changes can still be watched via the "Users to watch" list on https://bugzilla.gnome.org/userprefs.cgi?tab=email when the assignee is changed to an individual.]
So if I read comment #7 correctly, this bug is OBSOLETE by now. Please reopen if it's not. Thanks.