LV 8.5 Memory Leak using Networked Shared Variables

[Sima]

Hello,

We are using LV8.5. Setup is a PC and a desktop ETS. If I run the VI "test Network String.vi" and watch the memory in the RT System Manager, I see the used memory continuously increasing. You can make it creep faster by increasing the loop speeds. I don't see this happen with a single-process string variable, or maybe it's happening slowly.

Why is this happening? Is there a copy being created each time? Can anyone reproduce this on their system?

[Kevin_H]

Hey Sima,

Thank you for contacting National Instruments.  I was able to replicate this issue here are on our end.  I did some further testing, and it appears this error does not occur when using LabVIEW 8.2.1.  I was unable to find a Corrective Action Request, so we may have an undocumented bug here.  I will do some more work on this end, and report back what I find out.

Regards,

Kevin H

[hmechan]

Hi,

I have to admit that I am a newbie with Labview, but I would like to offer my little experience in a related issue.

I am currently helping my colleague to debug a memory leak problem with a desktop ETS application in Labview 8.5. There are approx. 200 network published shared variable in the project and we know that we are stretching the share variable engine.  Our main VI contains several time loops that are updated between 4 and 10ms.  We get some shared variable related warnings (-1950679034, -1950679035…) occasionally.  I would say we get a warning approximately once every 2 minutes.

If I don't clear those warnings, our target program takes up approximately 200kB of memory/sec based on the RT System Manager.

After some code blockings and isolations, I realized that the majority of the leak occurs when I pass a warning into the error in input of the shared variable read / write block.  If I clear the warnings at the beginning of the Timed loop, the memory leaks drops to approx 2K/minute.

I am still at a very preliminary stage on debugging my program, and I don't know if there is any other cause for the memory leaks.  My observation so far suggests that the leak get worst if a warning / error is generated, or if a warning is passed into the shared variable read/write block.

Simba,

I will try your project as soon as I finish testing my code.  Since there are two unsynchronized parallel loops in the vi, have you monitor if the shared variable calls generate any warning?

I am also looking forward for a resolution to that issue.  We have spent a couple weeks to stabilize our code. 

[Sima]

Thanks Kevin. This became an issue when we upgraded our main application from 8.2.1 to 8.5, and would crash overnight from "out of memory". This didn't happen with 8.2.1, and memory usage was pretty stable, even running the application for days on end. Now with 8.5, the memory usage leaks terribly. It is a serious problem, and seems strange to me that noone picked up on it before 8.5 was released.

We noticed a leak in the use of networked string shared variables, but we don't know if there are any other places where there might be leaks. I know there have been major changes to the shared variable engine in 8.5. I understand it is now based on TCP instead of UDP.

What is a workaround? Go back to old school TCP transfer?

[Kevin_H]

Hey Sima,

I have been working with another engineer, and we have notified R&D of this issue.  The Corrective Action Request ID# for this issue is 4FTCC85M.  I currently do not have a reilable workaround, other than starting over and using TCP. 

I will continue to work on the issue, and let you know what I find out.

Regards,

Kevin H

[Sima]

Hi Kevin, our local NI rep said there might be a patch/fix for this soon. Fingers crossed!

Thanks for your help,

Sima

[Ben]

Sima wrote; " local NI rep said there might be a patch/fix for this soon."

Please keep up updated.

Thanks!

Ben

[Kevin_H]

This was reported to R&D (# 4FTCC85M). R&D is currently investigating this issue. 

Kevin H

* This post was added for searchability *

[Jarrod_S.]

This might be related to Shared Variables containing strings, so an easy workaround you might try would be to convert your string variables to U8 arrays. There's a simple conversion VI in the String Palette called String to Byte array, and the reverse operation is there too. So convert your string to U8s, publish them to the variables, and then convert the U8s back to strings on the host side.

Will this work for you? It's fairly simple and straightforward, although it might be a pain if you have many instances of this or other string variables. You also won't be able to bind your U8 shared variable directly to a string control or indicator.

[Darin_G]

Here's an update just to tie this up.  The bad behavior was introduced with LabVIEW 8.5.   A fix went into LabVIEW/LabVIEW RT 8.5.1 to correct the issue.   The memory leak only happened when using network variables with the string datatype.

~cheers,

Darin G

LabVIEW R&D - Variables, Group Manager

Message Edited by Darin G on 05-04-2009 12:03 PM