Shared variables creating memory leak

[Tim_S]

Thought I'd pass this along and see if anyone can reproduce with different versions of LabVIEW. Appreciate it if anyone has seen this and has a fix.

I'm using shared variables to communicate between applications (1:N). I'd been seeing some memory creep that was inconsistent and somewhat bizarre. Eventually managed to track it down to that I'm programmatically opening a connection to a shared variable in one loop, then reading the value in a different loop (the different loops have to do with reconnecting on connection loss and startup). There is a functional global used to pass the variable to the second loop. The Read Variable primitive deallocates all but 4 bytes of memory for the previous loop handle and then allocates memory for a new handle on each iteration of the while loop, hence creating a leak. This behavior does not occur if there is only one loop where there is an open, while loop with a read, and a close.

Main.vi demonstrates the issue. Main 2.vi is more like the NI example.

I've got service request #7728859 with NI going, but I think I got the guy's first day.

LabVIEW 2015 SP1 32-bit on Win7 64-bit. Shared Variables memory leak.zip

[JKSH]

6 hours ago, Tim_S said:

Eventually managed to track it down to that I'm programmatically opening a connection to a shared variable in one loop, then reading the value in a different loop (the different loops have to do with reconnecting on connection loss and startup). There is a functional global used to pass the variable to the second loop. The Read Variable primitive deallocates all but 4 bytes of memory for the previous loop handle and then allocates memory for a new handle on each iteration of the while loop, hence creating a leak. This behavior does not occur if there is only one loop where there is an open, while loop with a read, and a close.

I don't have a fix for the leak (and I haven't investigated it in detail), but I have an alternative architecture for auto-connecting comms.

Instead of opening/closing in one loop and passing the variable reference to another loop, is it feasible to keep everything in one loop using a state machine? The states could be:

• Offline (the only state that's allowed to quit the loop)
• Connecting (contains the Open Variable node)
• Online (contains the Read Variable node)
• Disconnecting (contains the Close Variable node)

Button clicks, panel close events, and read errors can be used to trigger state transitions.

[ensegre]

I don't know if I'm looking at the same as you, and I haven't investigated either, but I don't see leaks. LV17 32bit Win (where else do you have SV?) 10. I suppose allocation and deallocation sizes might depend on the variable content too, don't they?

My trace has many more events, are you somehow filtering them? I don't fully understand your throttling of the second loop based on timeout of an occurrence, but there you know better, maybe it has to do with your architecture at large.

Untitled Project 1.lvproj.det

[Tim_S]

11 hours ago, JKSH said:

I don't have a fix for the leak (and I haven't investigated it in detail), but I have an alternative architecture for auto-connecting comms.

Instead of opening/closing in one loop and passing the variable reference to another loop, is it feasible to keep everything in one loop using a state machine? The states could be:

...

If I have to go back and refactor then I'll have something closer to that. The code is a communication library that gets used by anything trying to talk to an application. The Initialize launches a VI that opens and maintains the connection and then individual VIs get used to read the shared variables (thus the code using the library only reads what is needs). There's certainly other ways to do this, but it's worked well except for the memory leak.

[Tim_S]

5 hours ago, ensegre said:

I don't know if I'm looking at the same as you, and I haven't investigated either, but I don't see leaks. LV17 32bit Win (where else do you have SV?) 10. I suppose allocation and deallocation sizes might depend on the variable content too, don't they?

My trace has many more events, are you somehow filtering them? I don't fully understand your throttling of the second loop based on timeout of an occurrence, but there you know better, maybe it has to do with your architecture at large.

Untitled Project 1.lvproj.det

Sorry, should have mentioned I set the capture settings to have a memory threshold of 500 bytes. There are a lot of typically uninteresting allocations/deallocations occurring that spam the capture otherwise.

The memory allocated for a shared variable handle I would expect to be the same for a particular data type independent of the contents, though I've not dived this deep into the bowels of shared variables before.

The use of the occurrence is (an old) way to throttle loop rate and control parallel loop termination; used to see it quite a bit before events were added to LabVIEW. The bottom loop keeps running until the top loop ends at which point the occurrence is set. The timeout of the occurrence acts the same as a Wait (ms) of the same time.

[ensegre]

3 hours ago, Tim_S said:

Sorry, should have mentioned I set the capture settings to have a memory threshold of 500 bytes.

If I put such a threshold I see no memory events at all. Is you trace dependent on some particular data already present in your SV? Otherwise, it may be that the issue is solved in LV2017.

Edit: Ok, with more data in the string I see this (a different sequence of memory operations in fact):

But does this indicate a leak? I note the free of 4 bytes, which maybe you squelched with the threshold.

Edited January 11, 2018 by ensegre

[Tim_S]

20 hours ago, ensegre said:

But does this indicate a leak? I note the free of 4 bytes, which maybe you squelched with the threshold

Drat, you're right... Today I've had an IT-pushed Windows update and reboot that has changed the behavior to closer to your screenshot. I was able to eliminate the memory leak by completely eliminating all of the Read Variables in my application, so I know something's related.