Bug 11380 - xosview variable not initialised ?
Summary: xosview variable not initialised ?
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xosview
Version: 6.2
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-05-12 08:49 UTC by cradford
Modified: 2008-05-01 15:37 UTC (History)
0 users

(edit)
Clone Of:
(edit)
Last Closed: 2000-08-29 08:51:35 UTC


Attachments (Terms of Use)

Description cradford 2000-05-12 08:49:03 UTC
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 15:53:09 UTC
What value is not initialized? I don't see what needs to be fixed ...

Comment 2 cradford 2000-08-14 08:26:42 UTC
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 08:49:18 UTC
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 21:43:32 UTC
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.