Created attachment 102065 [details]
Screenshot

Which version ? In tree mode ?

Using trunk atm. If you mean "dependencies" with "tree mode", the answer is no. Check the shot above. The left side shows the list as I found it, after pressing the column to re-sort (pressing two times, to get /\ sorting again) the list is sorted correctly.

Does the list becomes sorted after the next update ?
Are unsorted processese new ones ?

As far as I can see, only new processes are affected. For example, I just started beagle-status, which was added to the top of the list (top=highest memory usage) with just about 400k memory usage. After a manual refresh (thanks to bug 506036), the beagle-status line moved to the second position... still much too high. I cannot reproduce this 100%, after another test the beagle-status process sayed at position 1, and after some time (more than the normal update interval) it was moved down. Strange...

there is similar bugs on launchpad, https://bugs.launchpad.net/gnome-system-monitor/+bug/206239 for example

I can see this bug from time to time, but never really understood it since we're not manually sorting the list.

Created attachment 116432 [details]
Another screenie of the bug

Observing the behavior it seems when adding a new task it's actually somewhat sorted into the list but ignores the multiplication unit so you get KBs mixed with MBs and possibly GBs.

I believe this is actually a kind of GTK+ bug or something related to the sort which is not instant. I think what you once see about the Memory column is not really relevant: if you just wait for all the updates too happen, the list eventually gets sorted.

Benoît:

My experience is quite the reverse. Once you set the sorting column everything behaves nice until a new process appears. Then it jumps somewhere in the middle yet still the list seems to be sorted according to the first digit (with no respect to the unit).

Then new stuff starts to sort around that inserted column like of GTK/system-monitor assumed the list was sorted beforehand so it stops looking for a new place once it encounters a row with a low enough value (which is out of place).

To put it in pseudo code I think the behavior is close to:

if new row added:
  for each old row starting from the top:
    if old row < new row (with some glitch around unit handling)
      insert new row before old row
      break

So once you get 200 KB between 30 MB and 15 MB (as it seems to work here), the next app to report 190 KB will jump in right below the 200 KB.

(If i look at your screenshot, it's not sorted alphabetically: 1_85, 8_5, ..., 1_9, etc.)

system-monitor fully updates the tree on each refresh and i don't know how/when the GTK+ sorting happens. And that operation is blocking, it's done in 1-pass and can take ~0.5s of CPU.
(When dependencies are off,) the new process is prepended to the treestore. It's just like a graphical update occurs while the tree is getting sorted.

Benoît:

Don't get me wrong. I've actually read the code of g-s-m and I know when not in tree mode it just inserts with NULL as position. It's just I find gtk behavior to be funny as sometimes the sorting makes some sense (like I said once you get a rogue process, others tend to bunch around it) even if it's completely random.

I appreciate your comments. I have once tried to write some test cases un pygtk but i wasn't able to reproduce.

I'm not really concerned about new processes.
When system-monitor starts it fills the treestore. But some stats like the X memory are not immediatly available but they are on the second refresh. So if your tree is memory sorted, this triggers the same bug: when the X memory usage gets accounted, many process move from a few MB of memory to many dozens, and the tree gets messed.
=> you have to wait at least 3 updates to get the correct top-by-memory processes.

*** Bug 535278 has been marked as a duplicate of this bug. ***

Still 100% reproducible with 2.24.1 with these steps
- order by memory
- open firefox and load some sites (it will take more than 100MB of memory)
- open gnome-terminal
- you will see gnome-pty-helper on top of the process list though it's just 750KB.

Still 100% reproducible in 2.28.0:

- View->Active Processes (this is easiest to see)
- Click on %CPU column
- Watch the high-CPU items in the list jump around every time the list refreshes.

Bug 581716 is probably a dup of this.

*** Bug 581716 has been marked as a duplicate of this bug. ***

Works for me; sorting seems fine in 2.28.2 (openSUSE 11.4).  When sorting by "%CPU" the bust processes stat at the top of the list.

A patch fixing this issue (as a side-effect of another fix) is available in bug 557122.

The patch Robert mention has been merged in commit b439f813ceaf6ce6e82cd490c734c67aeb1f2028 and shoudl fix this.

*** Bug 622403 has been marked as a duplicate of this bug. ***

*** Bug 670816 has been marked as a duplicate of this bug. ***

Created attachment 208457 [details]
This screenshot shows incorrect sorting of the 'Memory' column.

This bug is still reproducible, at least in regard to the sorting of the 'Memory' column.

I'm attaching a screenshot of this problem.

I filed a separate ticket for this 'Memory' column sorting problem as bug 670816, but that has been marked as a duplicate of this ticket.

I see that this ticket is marked "RESOLVED FIXED".  If bug 670816 is to be treated as a duplicate of this ticket, then this ticket should be "FAILED", and its status changed back to "UNRESOLVED".

Unfortunately my account does not have the privileges to edit this ticket, so I cannot change its status.

If bug 670816 is to be treated as a duplicate of this ticket, then I hope that whoever has the privileges can "FAIL" this ticket back to "UNRESOLVED" based on the problem I'm seeing depicted in the screenshot I'm attaching.

(In reply to comment #24)

Cloned the git repo, looked through the log of the 'master' branch.  As I understand Robert's fix merged by Chris in commit b439f813ceaf6ce6e82cd490c734c67aeb1f2028 as described in comment #21 makes this bug fixed for release 3.3.4 :)