Bug 11380 - xosview variable not initialised ?
xosview variable not initialised ?
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: xosview (Show other bugs)
6.2
All Linux
medium Severity low
: ---
: ---
Assigned To: Preston Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-05-12 04:49 EDT by cradford
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-29 04:51:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description cradford 2000-05-12 04:49:03 EDT
xosview decay fields have random values at startup. Particularily the disk
access averaging, which is often negative ( on my setup :>), causing
oveprinting of the field label. As far as I am aware, this has happened in
all versions from 5.0 on.
Comment 1 Jeff Johnson 2000-08-11 11:53:09 EDT
What value is not initialized? I don't see what needs to be fixed ...
Comment 2 cradford 2000-08-14 04:26:42 EDT
The bug is >> xosview decay fields have random values at startup << I am only 
guessing that some values have not been initialised.
The meter bar ( lest assume bar mode ) is supposed to start on the left hand 
side of the window ( next to its appropriate label ) and progresses widthways 
towards the right. NOT ON MY SYSTEM. On initial invocation of xosview, the 
"decay" meter bars do not start at zero and progress right to their correct 
"average value". They often start at zero and progress left( i.e. negative ) 
overprinting the meter bar label. This sometimes causes xosview to core dump, 
sometimes not. Given time this "negative" value decreases, once the correct 
values have been reached, it never again decays below zero, and never core 
dumps. I am guessing it is an xosview initialisation problem, as it only occurs 
when the the meter fields have no "history" to base the calculated "average" 
values on. The "instantaneous" meter values work fine it is confined to the 
"average" meter values.
Comment 3 cradford 2000-08-29 04:49:18 EDT
I managed to rip this off the console before the "core"

value 63, width -1, total_ = 5e+06
fields_[0] = 0,fields_[1] = 0,fields_[2] = 5e+06,
fieldmeterdecay.cc:146
FieldMeter::checkX() : bad horiz values for meter : DiskMeter
value 62, width 136, total_ = 5e+06
fields_[0] = 0,fields_[1] = 0,fields_[2] = 5e+06,
fieldmeterdecay.cc:146
FieldMeter::checkX() : bad horiz values for meter : DiskMeter
value 63, width -1, total_ = 5e+06
fields_[0] = 0,fields_[1] = 0,fields_[2] = 5e+06,
fieldmeterdecay.cc:146
FieldMeter::checkX() : bad horiz values for meter : DiskMeter
value 62, width 136, total_ = 5e+06
fields_[0] = 0,fields_[1] = 0,fields_[2] = 5e+06,
fieldmeterdecay.cc:146
FieldMeter::checkX() : bad horiz values for meter : DiskMeter
value 63, width -1, total_ = 5e+06
fields_[0] = 0,fields_[1] = 0,fields_[2] = 5e+06,
fieldmeterdecay.cc:146
FieldMeter::checkX() : bad horiz values for meter : DiskMeter
value 62, width 136, total_ = 5e+06
fields_[0] = 0,fields_[1] = 0,fields_[2] = 5e+06,
fieldmeterdecay.cc:146
Comment 4 Preston Brown 2001-01-31 16:43:32 EST
should be fixed in 1.7.3 and up, soon in rawhide.  Please re-open if you
experience any more similar problems.

Note You need to log in before you can comment on or make changes to this bug.