LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

memory leak shared variables

State of mind

I am getting desperate by now Smiley Mad

 

Current Situation

I am using LV2010.

I use the SV functions in the functions pallette -> data communication -> shared variable -> PSP variable.

I use the vi: read variable with timeout

I use this vi in a loop.

If it generates an error (because the connection was lost or whatever) I close the connection using: close variable connection.

I then try to open a new connection (autorecovery) using: open and verify variable connection.

If this vi generates any kind of error I again close that connection using: close variable connection

 

I traced the memorleak to: open and verify variable connection

 

Conditions:

There are about 10 PC's each (sometimes) running a program which if started locally host a network shared variable container called 'backend_vars'. This container has a variable called 'Settings'. If the program shuts down the shared variable container is also disposed (so after the program is shut down 'backend_vars' and 'settings' do not exist anymore) These are the conditions I have to work with. They are not changeable. So to make my point, this is not what the problem is about.

 

I use another PC to connect to the variable 'Settings' on each PC and extract some info from that variable.

 

Behaviour

For some reason, whenever you call open and verify variable connection.vi memory is used. In task manager I see an increase of about 4kb per second. If I disable this vi in my program, the memoryleak no longer exists. I also tried to use the property nodes, to search for the existence of this variable. If it exists I use the open function. However, the property nodes also seem to have this memoryleak.

 

ANYBODY IDEAS?

0 Kudos
Message 1 of 7
(3,554 Views)

Sorry I forgot to add a nice picture (see attachment)

0 Kudos
Message 2 of 7
(3,547 Views)

Repeatedly opening connections will result in increased memory usage.

 

For connections that can come and go I will devise code that opens the connections once and caches same (similar to the Singlton Pattern) and then repeatedly use the same connection as long as it is a live. If the connection fails I close the old and open a new, but only when required.

 

In my scenario I get the same memory demands (4K per connection or there-about) but I increase the requirements when the old connection fails.

 

Caching the refs also increases performance since no malloc required for the new connections.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 7
(3,545 Views)

I do use the same connection as long as it is alive. However, I have those 10 PC's that I have to 'poll' for the existence of the SV container. This in itself, using the SV toolset, results in a memoryleak. How can I cache a reference of a SV? It's a purple kinda wire but deffinately not a greenish reference wire. Could you give me a small example of what you mean? I would really appreciate.


Would changing my code using datasocket solve the problem? I guess I have to change it, cause this is not really working for me. I totally do not understand why NI implements a SV toolset, encourages everybody to use it and then if you use it, you run into all kinds of problems like this memoryleak. What's the point of having this toolset? Theoretically I have done everything right. It is already taking a weak of my time to debug this.

 

Anyway, thanks for your assistance.

 

Kind regards,

 

Maurice

0 Kudos
Message 4 of 7
(3,534 Views)

@Maurice_01 wrote:

I do use the same connection as long as it is alive. However, I have those 10 PC's that I have to 'poll' for the existence of the SV container. This in itself, using the SV toolset, results in a memoryleak. How can I cache a reference of a SV? It's a purple kinda wire but deffinately not a greenish reference wire. Could you give me a small example of what you mean? I would really appreciate.


Would changing my code using datasocket solve the problem? I guess I have to change it, cause this is not really working for me. I totally do not understand why NI implements a SV toolset, encourages everybody to use it and then if you use it, you run into all kinds of problems like this memoryleak. What's the point of having this toolset? Theoretically I have done everything right. It is already taking a weak of my time to debug this.

 

Anyway, thanks for your assistance.

 

Kind regards,

 

Maurice


Datasockets would solve your problem, give you greater control, and greatly simplify situations were you have to scale-up since you can generate the URL's dynamically.

 

I have far too many post for you to search but if you did, you would find that I have never been a fan of Shared Variables for many reasons in addition to those you have listed.

 

There is yet another alternative that used to be taught as "The Standard" in the LV 6i version of the RT course.

 

VI Server

 

VI server will work across process contexts on the same machine or similarly cross platform. I believe I can can safely state that I have either developed or supported thousands of VI Server instances running for almost nine years now controling Jet Engine simualtors, storage of blood, Well fracking, and many many more.

 

What I generally do is implement an Action Engine that contains the data structures I need to share with methods as required to check/touch the data for all of the clients of that data. The Action engine by its very nature prevents Race Conditions (try to do that with a shared variable). Since the data is acted on "In-Place" the AE's are efficient. There are alos a number of properties and methods for the Application refernce that can be used to monitor and control the connectivity to teh target machines so rather than being diabled by the lack of functionality in the SV's we as developers are enabled.

 

Now to your question as to "why..."

 

Not being a fly on the wall when the decision was made, I can only respond by asking...

 

Why do they make kids use those huge crayons in kindergarten? They are so large that any skill acquired using them is not useful when weilding a real writting instrument. Sure the kids think the product of those crayons are beutiful but anyone who really knows how to draw would reach for another more appropriate tool.

 

So DataSockets or VI server and of course you could "roll your own" using TCP.

 

Your partner in wire,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 5 of 7
(3,522 Views)

I changed my code to use datasocket using a psp:\\localhost\container\variable url.

I also used the 'action engine' as you described.

 

Unfortunately both give me a terrible memory leak.

 

As I understand, a datasocket open and close should be outside a loop. However, I do not have that luxury, because I am constantly scanning if a computer was turned on or off. If the connection exists or not. So I constantly have to poll. So I have to try to open connections and close them in the same loop constantly.

 

How can I do this?????

 

Kind regards,

Maurice

 

PS. I added png files of my code.

Download All
0 Kudos
Message 6 of 7
(3,501 Views)

I Maurice,

 

So much to say so little time to say it.

 

For application that come and go I have used various techniques.

 

1) UDP

The nodes offering a servie i need, they will use a UDP broadcast message to announce their precence and the IP. No polling required just keeping track of UDP messages. This is basically how a PC finds a network printer.

 

2) Re-entrant watcher It can use pings to see if the node is on the network. No memory leaks. If it is there take the next step of trying to connect.

 

3) Re your action engine. The open should only do an open once to establish the connection. Keep the connection ID in a SR and use a boolean in another SR to keep track if the connection was good when last used and if so skip the open and just use the previous connect ID.

 

4) Invoke a dynamic VI that checks fo rthe node and writes a file if it is there and then closes itself. If your find the file then it is worth attempting to connect.

 

Generally...

 

OPens should only be done when required and once connected keep the connection until it turns bad and only then re-attempt the connection.

 

Just trying to give some ideas to work with.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 7
(3,485 Views)