Ticket #2140 (closed bug: fixed)

Opened 9 months ago

Last modified 6 months ago

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 development
Cc: Blocked By:
Platform: All Blocking:

Description

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

ActivityMonitor.png (75.0 KB) - added by bga 9 months ago.
ActivityMonitor bug.
screen1.png (131.4 KB) - added by bga 6 months ago.
New screen capture.

Change History

Changed 9 months ago by bga

ActivityMonitor bug.

Changed 9 months 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.

Changed 9 months 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.

Changed 6 months ago by axeld

  • status changed from new to closed
  • resolution set to fixed

Fixed in r26409.

Changed 6 months ago by bga

  • status changed from closed to reopened
  • resolution fixed deleted

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.

Changed 6 months 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 6 months ago by bga

New screen capture.

Changed 6 months 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.

Changed 6 months 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.

Changed 6 months ago by axeld

  • status changed from reopened to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.