Memory leak in System Configuration API

[Eric_Simon]

Sure enough, I implemented the FGV-style interface and the memory leak is gone!  It's definitely in the way the session is being opened/closed.

[0utlaw]

Eric,

Thanks for the update, and glad to hear that worked for you.  As Bilko suggested, it might be worth pinpointing whether the leak is due to the sessions not being released or if they're just not closing fast enough- is this function getting called at above-normal priority and/or is your controller running near its CPU limit? Either of these could be starving the sysconfig process.  It's also possible that it takes longer to release the session behind the scenes and you were building a buffer of almost-closed sessions due to multiple calls.  Either way, I'd like to look at it further.  I probably will when I've got time.

Regards, 

[Eric_Simon]

Another tid-bit of information that may help...

I doubt that it is the case that the CPU isn't keeping up with the open/close.  The reason I say this is that first, CPU is running at about 10%.  Second, the system has two modes of operation.  The posted funciton occurs in one of the modes.  When I switch out of this mode, the memory leak ceases (i.e. memory stays constant).  However, none of the memory gobbled up when in this mode is returned to the system after switching out.

For example, I'm running at 74 MB.  I switch to the mode with the SysConfig funciton and memory starts to creep.  Say when I switch back out of the mode, memory is now at 84 MB.  The system stays at 84 MB indefinitely.  I switch back into the mode and memory begins to climb again.

Thanks again!

Eric

[gregoryng]

Hi Bill (and others),

I wanted to add that think I'm also having some memory leaks in the System Configuration API.  I've attached the simple test VI that I use, which only opens one session and then repeatedly polls the temperature at a relatively slow rate (1 Hz).  I've seen the memory reduce by hundreds of MB.  When the VI started, the system had 1.863 GB free, and at the end had only 1.475 GB free after 2300 seconds (i.e., ~176 kb leaked per call)

I'm running Labview 2011 with System Configuration API 5.5 I believe on a PXIe-8133 controller with ~2 GB RAM.  

[gregoryng]

Hi everyone,

I just wanted to give an update on my issue.  I filed a service request for the memory leak behavior I was seeing.  NI was able to replicate my issue and identified a memory leak that occurred when attempting to read the temperature from signal generator PXI modules via the System Configuration API.  The leak did not occur when reading directly from the FGEN API for device temperature, so this can be used as a workaround.  The issue did not appear to affect any other properties that I tested. They issued a corrective action request CAR #434355 but did not give a definite timeframe for a fix.

I was using Labview RT 2011, NI FGEN 2.9.3, DAQmx 9.7.5, and System Configuration API 5.5 at the time I filed the service request.