Karl Chen <[EMAIL PROTECTED]> writes:
> Now that I've gotten this far I figure it should be easy to
> reproduce :) Just play back the values to a CurveView monitor.
>
> It looks to me like a chain of bugs triggered by an unlikely
> scenario: 1. The value shouldn't be 2e19 in the first place (is
> this bytes/sec?) - possible glibtop bug. 2. A huge number like
> that shouldn't confuse hardware-monitor. 3. Weird point values
> like that shouldn't corrupt memory - possible bug in
> libgnomecanvas or libart.
I'm sorry I haven't had the time to deal with this before. This was an
extremely good bug report.
> hardware-monitor debug # 18264
> Monitor: Eth. 1 (Ethernet (first))
>
> values (34):
> 1.84467e+19
> 1.10954e+07
> 1.0973e+07
I still haven't figured out how the very large value enters the
system, though. I currently tend to think that it happens because the
interface is reset and I then get a negative value which by the virtue
of unsignedness is converted to a very large number.
I'm attaching a simple patch that perhaps fixes this. Could you please
see if it helps?
--
Ole Laursen
http://www.cs.aau.dk/~olau/
Index: src/monitor-impls.cpp
===================================================================
RCS file: /cvs/gnome/hardware-monitor/src/monitor-impls.cpp,v
retrieving revision 1.14
diff -u -r1.14 monitor-impls.cpp
--- src/monitor-impls.cpp 11 Feb 2006 20:44:02 -0000 1.14
+++ src/monitor-impls.cpp 10 Sep 2006 18:09:52 -0000
@@ -629,7 +629,7 @@
if (byte_count == 0) // no estimate initially
val = 0;
- else if (measured_bytes == 0) // interface was reset
+ else if (measured_bytes < byte_count) // interface was reset
val = 0;
else
val = measured_bytes - byte_count;
