Closed GoogleCodeExporter closed 8 years ago
[deleted comment]
the exception is thrown exactly here in GenericCPU.cs
try {
// make sure always the same thread is used
mask = ThreadAffinity.Set( 1UL << cpuid[0][0].Thread );
} catch (Exception ex) {
throw new Exception( " Generic Block 1 " + ex.Message );
}
But cpuid is not null and thread also not. So it is something inside
ThreadAffinity
Original comment by worldbeh...@gmail.com
on 2 May 2011 at 9:20
[deleted comment]
So my debug session is finished. When startet the Tool first cpuid[0][0].Thread
contains 1 as a number. Then it is set. When i call update the bitshifting in
the code above creates an int with the number 0. So now he tries to set the
thread to 0. I think the SetThreadAffinity function will fail then.
Original comment by worldbeh...@gmail.com
on 2 May 2011 at 9:58
I don't really understand where the problem is. If the NullReferenceException
is thrown in ThreadAffinity.Set, then this should show up in the stack trace as
well. So the only thing that is null could be either cpuid[0] or cpuid[0][0].
But looking at the constructor I doubt that these are null. Can you send me a
minimal application that produces the exception?
Original comment by moel.mich
on 2 May 2011 at 11:00
Here is the application code.
The action method is called every minute. When the sensors are added, cpu
temperature is just shown fine. After the minute, i call the update function of
the hardware and then my exception is thrown.
Before i updated to the new version the application code worked fine and i saw
that there were many changes in the update method.
Original comment by worldbeh...@gmail.com
on 2 May 2011 at 11:11
You should not call Computer.Close() while you are still using the sensors. The
Computer class provides the global context for all hardware access. The
Computer.Close() method has to be called when you are finished with using the
interfaces obtained from a Computer instance.
Also it is not a very good idea to call sensor.Hardware.Update() for each
sensor, because this causes the hardware (CPU for example) to update all its
sensors multiple more often than needed. One call to hardware.Update() is
enough to read all sensors of that hardware after that.
Original comment by moel.mich
on 2 May 2011 at 12:07
thank you.. i .. just came to this now too.. i am sorry :D i am using now an
UpdateVisitor like in yours and of course i do not call Close() anymore.
Stupid.. i guess i have to throw a cent in the pennyswine ...sorry for wasting
your time
Original comment by worldbeh...@gmail.com
on 2 May 2011 at 12:20
no problem, from these things I see that the interface of the library is still
not that "fail safe" I would have liked it to be. But then again it was
originally never designed for a library. At some point I might look into
simplifying a few things.
Original comment by moel.mich
on 2 May 2011 at 2:02
Original issue reported on code.google.com by
worldbeh...@gmail.com
on 2 May 2011 at 8:39