LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Memory Leak LabVIEW 2013 with User Events

I am seeing a significant memory leak in 2013 (f1) when using event to pass data in a "certain situation".  This memory leak does not occur in 2012.

 

The situation is the following:

There are two top level vi's in the program (exe in this case).  Use VI server to interface with one of the vi's (lets call it "Interface").  Interface checks if the other vi (lets call it "Engine") is already in memory and running.  If "Engine" is not open then "Interface" opens "Engine" using the path and vi server.  It runs "Engine" with autodispose ref = T.  It then waits until a boolean on "Engine" is set which means the vi has initialized the user event references to use to pass information back and forth.  Next "Interface" will then send the data to "Engine" which includes the function and data using a user event reference (obtained using VI Global method to lookup reference opened in Engine).  "Interface" waits for "Engine" to complete by waiting for a different user event that includes the data sent back from the function called in "Engine".  That data is sent to the front panel \ connector pane of "Interface" and passed back to the originally caller using call by reference node or getting the data via get control value.

 

The original implementation used activeX to open a reference to "Interface".  Interface would run, then become idle, then run again, and then idle (Engine is always running).  This approach exposes the memory leak.  I changed the implementation today to use VI server to communication with the VI in the EXE.  If I call "Interface" in a loop by opening "Interface" then close the reference to "Interface" and the application then I see the memory leak.  However, if I open the reference to the app and "Interface" and keep that reference open while looping on the call to "Interface" then I don't see the memory leak.

 

From what I have seen it has something to do with either passing the data to the event structure or getting the data back and one of the vi's going idle.  There is no obvious reference leak in either vi (used Desktop Execution Trace Toolkit and no refs left open).  And again the program has no memory leak in 2012, but is seen in 2013.  The reason I think that it may be somewhere in the user event or event structures is that the more data I pass to the interface the larger the memory leak.  See attached images for a visual on what is going on.

 

Caller Memory Leak Not Seen

Caller-MemoryLeakNotSeen.PNG

Caller Memory Leak Seen

 

Caller-MemoryLeakSeen.PNG

 

Interface States called (Engine Already Running)

 

Interface_StatesCalled(AssumedEngineAlreadyRunning).PNG

Engine States Called (Engine Already Running)

Engine_StatesCalled(AssumedEngineAlreadyRunning).PNG

0 Kudos
Message 1 of 3
(2,654 Views)
  • How much memory is it leaking?
  • What happens if you slow the "leaking" loop down?
  • Does this leak occur with calling any VI, or just this one specific VI?
  • What happens of you have just the open/close application reference functions outside the loop?

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 3
(2,634 Views)
Leaking significantly. If the data passed into the function is large. A much smaller memory leak if only the cluster is sent with a function name and not data. MB per run with larger data. KB or less per run with just function name.

No effect...besides the loop going slower.

Any vi that uses the user event to pass data to the engine. If the vi ever goes idle between runs. I used a separate interface vi for vi server and for active x interface. Same problem. I did not try a vi that recived large data from the caller but did not pass data to the engine. I am guessing I would not see a leak, but not confirmed.

If you only open and close you don't see a leak.
0 Kudos
Message 3 of 3
(2,624 Views)