austinulmer / open-hardware-monitor

Automatically exported from code.google.com/p/open-hardware-monitor
0 stars 0 forks source link

Exception bei IntelCPU.Update() #202

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago

Hello there,

i am using the new Version 0.3 and the OpenHardwareMonitorLib in an C# Tool. 

In the past the tool has been working but now i receive an null exception when 
calling the Update function of an cpu hardware to "refresh" cpu temp values.

Code looks like:
foreach (ISensor sensor in sensors.Values) {
                    if (sensor.SensorType.Equals(SensorType.Temperature)){
                        controller = sensor.Hardware;
controller.Update() << Exception

Exception Message:

System.NullReferenceException: object reference not set to an instance of an 
object.
   at OpenHardwareMonitor.Hardware.CPU.GenericCPU.Update()
   at OpenHardwareMonitor.Hardware.CPU.IntelCPU.Update()

Additional Info:
When first receiving the Sensors, an temperature value is reported correctly. 
It is just concerning the Update function.

Oddly the Open Hardware Monitor itself is running, just the Tool using the 
Library is not working.

Original issue reported on code.google.com by worldbeh...@gmail.com on 2 May 2011 at 8:39

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

Attachments:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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