Opened 11 years ago

Closed 11 years ago

#2140 closed bug (fixed)

ActivityMonitor shows graphics at the 0 position for positions close to the current one.

Reported by: bga Owned by: axeld
Priority: normal Milestone: R1
Component: Applications/ActivityMonitor Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


Besides what is described in the title of the bug, it also shows the current numeric values as 0 although it *IS* obviously correctly reading the data as in positions after a few seconds in the history it does show correct past values. The screemshot will probably make the problem obvious.

Attachments (2)

ActivityMonitor.png (75.0 KB) - added by bga 11 years ago.
ActivityMonitor bug.
screen1.png (131.4 KB) - added by bga 11 years ago.
New screen capture.

Download all attachments as: .zip

Change History (10)

Changed 11 years ago by bga

Attachment: ActivityMonitor.png added

ActivityMonitor bug.

comment:1 Changed 11 years ago by axeld

Yes, that's a known problem; it happens because of the way the current value is computed - since the data source retrieval happens in the window thread, it can easily lose a value (for example when doing a screenshot). Even if it would not run in the window thread anymore (which would make this problem a lot less likely), it might still lose a value under heavy load.

comment:2 Changed 11 years ago by bga

I don't quite understand what you mean (although I did not look at the code yet so this could be just it). I guess you are using a Message Runner or Pulse to update the data. Wouldn't it be better if you then retrieved the data when updating the values and kept track of the delta between the time of the last update and the current time? This way the graphic may not be accurate for small intervals but at least it would be a better representation than dropping the value to 0. :)

Also, do you actually force the numeric values to be displayed to 0? Because if they just retrieve the information from the system, I don't see how come they can get a 0 value no matter if the CPU is pegged or not.

comment:3 Changed 11 years ago by axeld

Resolution: fixed
Status: newclosed

Fixed in hrev26409.

comment:4 Changed 11 years ago by bga

Resolution: fixed
Status: closedreopened

Maybe it is not exactly the same problem but the memory graphs still look wrong. They are stuck at the 0 position (although currently there is 378.9 Mb used with 190.6 mb of cached memory. The graphic didn´t change even once since boot. staying flat at position 0.

So, reopening.

comment:5 Changed 11 years ago by anevilyak

Are you sure you rebuilt your stuff properly? It works fine over here, watching the cache / mem graphs steadily increase during an SVN checkout. How much RAM is on the box you're trying this with? mine's 1GB. Also, is the mem graph the only one you see issues with?

Changed 11 years ago by bga

Attachment: screen1.png added

New screen capture.

comment:6 Changed 11 years ago by bga

Yes, I am.

Tried at home with a Intel Core 2 Quad Extreme and 4 Gb of memory (around 3.5 detected by Haiku).

Tried again here at work under VMWare with a full build (erased the generated directory). Configured with 2 Gb of RAM and one virtual CPU. Started a svn checkou and with around 20% of the memory used, the graph was still at position 0 (see new screen capture).

I only have this problem with the memory monitors. Others work but I just noticed that in the CPU monitor, the graph keeps changing. From one redraw to another, peaks and valleys disappear and reappear again, which is kinda odd.

comment:7 Changed 11 years ago by bga

So if I change the memory amount in VMWare to 1 Gb, it works as expected. I guess there is a signed int overflow somewhere.

comment:8 Changed 11 years ago by axeld

Resolution: fixed
Status: reopenedclosed

That's a different bug that should have always appeared with more than 2 GB of memory. Anyway it's fixed in hrev26430.

Note: See TracTickets for help on using tickets.