NI4882 Device.ReadString() OutOfMemoryException

[dougec]

I have written a program that queries a Network Analyzer over GPIB using an NI PCI GPIB card and the NationalInstruments.NI4882.dll.  The reads in these queries are done using the NI4882.DLL's Device.ReadString().  The following is my read code:

---

string read = string.Empty;

try

{              

  read = _device.ReadString();

}          

catch (Exception e)

{              

  string err = string.Format("Failed to read.{0}{1}{2}{3}", Environment.NewLine, e.Message, Environment.NewLine, e.StackTrace);

  OnError(err);

  throw new Exception(err);

}

return read;

---

The program collects a very large amount of measurements, which takes 6+ hours to complete.  During a test run, the program crashed due to an OutOfMemoryException thrown by the _device.ReadString() function.  The StackTrace of the exception pointed to a StringBuilder object in the ReadString() function:

System.OutOfMemoryException

  at System.String.GetStringForStringBuilder()

  at System.Text.StringBuilder.ctor()

  at CommonImpl.ReadString()

  at DeviceImpl.ReadString()

  at Device.ReadString()

  at NI488Gpib.ReadString()  // <--- This is my function

My program repeats the same routine: calls ReadString() to get a measurement, Stores the data, Repeats, so it doesn't seem to be anything in my local code.

I was wondering if this was a known issue and if there are any workarounds?

Thanks,

-doug

[Kyle_M]

Doug,

Is the program failing in the same spot each time, including same time since start/iteration count/points received? Is memory usage climbing during the routine, and if so, how high does it get to when it crashes?

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments

[dougec]

---

Kyle,

We have only encountered the problem this one time.  Considering the test takes upwards of 6 hours and we are nearing a deadline for customer delivery we haven't had an opportunity to retry the test.  Instead, I was able to avoid the error by using the Device.ReadByteArray() function instead.  My GPIB read function has been updated to this:

---

string read = string.Empty;

try

{               

  byte[] bRead = _device.ReadByteArray();

  read = Encoding.ASCII.GetString(bRead);

}         

catch (Exception e)

{             

  string err = string.Format("Failed to read.{0}{1}{2}{3}", Environment.NewLine, e.Message, Environment.NewLine, e.StackTrace);

  OnError(err);               

  throw new Exception(err);

}           

return read;

---

This seems to be a fix for me, but there still may be an issue with the ReadString() function.  The error occurred at around 85% of the test time.  The memory in the application was high, at about 170MB when it crashed.  However, this may be expected since the application is holding a large amount of accumulated measurement data during the test (it stores it all upon completion). 

In our current implementation (using Device.ReadByteArray()), the memory slowly rises, but the application never crashes.  So far we have been able to complete 2 full runs without any problem.

[Kyle_M]

Doug, 

Its good to hear you were able to find a workaround for this issue. Let me know if you run into similar behavior again. 

Regards,

Kyle Mozdzyn

Applications Engineering

National Instruments