issues with labview and memory leaks

[cosmin]

Hi, we have an issue with labview build applications and win2000 sp4. The computers where the two apps are working are controlled remotely from time to time, so the applications are not monitored. After some time, a day or two, one of the application (can be any of the two) starts consuming memory until the computer freezes. If a user starts controlling the computer and maximize and minimize the panel of the application the memory is instantly released and all comes back to normal. Also the memory leaks was observed with the DataSocked (cwdss.exe process) and the sollution is the same.Does anyone have any explanation of this?thankscosmininstronica s.r.l.

[JoeLabView]

Do you have a loop where references are opened.  This could be for anything like openeing a reference to a file, a datasocket, an ActiveX class, etc..
If so, is the reference being closed?  Typically, you would want to open the reference before any loop, so that it is opened only once, and then closed after the loop when you no longer need it.
However, the above is only speculation because we would need to see your code to make any type of assessment.
R

[cosmin]

I forgot to mention we use labview 8.5.1 (I will disregard the post from Joe)cosmin

[drewsky]

I wouldn't disregard the post from Joe, from the info we have been given, that's about all of the conclusions we can come to.  We could google the exe, and see if there are reports of memory leaks, but you probably already did that.  So like Joe said, to determine why it is leaking, we need to see the context in which it is used.  Message Edited by drewsky on 08-06-2008 03:03 PM

[cosmin]

Hi, the issue is about Labview 8.5.1. and win2000 and user interface. Memory leaks appears only if there is no user activity on the computer for a day or two. I maintained the applications from labview ver 6 to Labview 8.5.1. The problems began with 8.5.As I said in the original post, the same issue appear with DataSocket server on the same computers.The post is intended for NI guys, for a workaround until Labview 9 or I need to force the client to switch to XP.

[Karunya_R]

Hi Cosmin, I have not heard of this issue before with other customers. - Can you please post your code so that I can test the issue itself?
- Is there a reason that you want to stick with Win 2000 and not move to Win XP?

[cosmin]

Hi,
I can't post any code.
The problem is that a shift to XP is not easy because it's about critical control applications for this client and 6 computers that cannot be shut down like that. The situation is still ok because we use computer redundancy so if one fails is always another one that takes control. Also there are different applications from different supplier that I cannot be sure that will work well on XP (I can't take that risk).
I considered the shift to labview ver.8 but I need to recode some of the modifications made for ver. 8. 5. (the DSC part as we shift from the old tag engine that was running perfectly to shared variables).
One sollution was to create a new application that programaticaly maximize and minimize the front panel for the 3 labview built app that runs simultaneous on that computer but in critical situation when the user need to make some decisions that app can create problems.
It bugs me that the DataSocket server creates the same problems and also the fact that problems arises only on 4 out of 6 computers. The 2 computers that never had any problems are also with win2000 sp4 but there the app are the old versions from labview 7.1 (kept as comparison with the new apps).
 
cosmin

[Albert Geven]

Hi I can remember a situation like this but in LabVIEW 7.1 a few years ago.I'm sorry I don't know the solution anymore but you can look on LAVA http://forums.lavag.org/home.htmland maybe find something.There should also be something like a call to the garbage cleaner (in LabVIEW) but instead of giving you a false linkI rather keep it to suggestions.In any case this is been sen before.

[Ben]

Since we can't look at your code I can only guess based on your clues.
Please review this <a href="http://zone.ni.com/devzone/cda/tut/p/id/7324#46630 2VO0SF00 by Category" target="_blank">known issue report </a>about datasockets leaking memory. The posted work-around is to open once use and then close.
Ben
BTW: THe LV 6 &gt;&gt;&gt; LV 8.5 DSC upgrade work is a real pain in the b$#% !

[Karunya_R]

Hi Cosmin, Like Ben pointed out, it is a known issue in LabVIEW 8.5+. This begs the question, are you using ActiveX VIs to perform Datasocket opening and closing?

[cosmin]

Hi,
I do not use DataSocket ActiveX VIs. Does anyone seen memory leaks with DataSocket server?
cosmin&nbsp;

[juliodiaz]

Que tal Cosmin,Tuve el mismo problema que tu, usaba LabVIEW DSC 7.0 y migré a LabVIEW DSC 8.6, y como ya han publicado<a href="../view_profile?user.id=95073" class="auth_text" style="font-weight: bold;" target="_blank"></a> Ben y Karunya R, es difícil encontrar la solución a algo si no podemos ver tu problema. Este ejemplo solucionó mi problema, espero solucione el tuyo.Hay algunas cosas que difieren de tu aplicación. Yo estoy usando Win XP SP3. Es recomendable que empieces a considerar cambiar tu sistema operativo a Win XP o Windows Vista, pues Windows 2000 pronto dejará de tener soporte por parte de Microsoft y cada vez será más difícil solucionar tus problemas con este sistema operativo.Saludos, Julio DíazMensaje editado por juliodiaz


DataSocket Memory Leaks.JPG:
http://forums.ni.com/attachments/ni/170/348833/1/DataSocket Memory Leaks.JPG


DataSocket Memory Leaks1.JPG:
http://forums.ni.com/attachments/ni/170/348833/2/DataSocket Memory Leaks1.JPG

[Karunya_R]

Hi Cosmin,&nbsp;If you can't post the whole code, it is possible for you to replicate the problem and put up a smaller piece of code to test. It is difficult to come to any type of conclusion without having something to work with.&nbsp;

[jlokanis]

Regarding the DS memory leak, would the following VI leak in LV8.5?&nbsp; We call this VI severla times in our code (but not in a loop).&nbsp; Does it matter how many times we call it?&nbsp; Does the leak only happen if we call it several times quickly?&nbsp; Do I need to cache the DS ref so I only call open once?&nbsp;-John


Write Output.vi:
http://forums.ni.com/ni/attachments/ni/170/349169/1/Write Output.vi

[Karunya_R]

Hi John,&nbsp;Are you seeing a memory leak? The only known issue with memory leaks and data sockets is when you use data socket active X VIs. The issue and the workaround is posted <a href="http://zone.ni.com/devzone/cda/tut/p/id/6449#46630%202VO0SF00%20by%20Category" target="_blank">here</a>.&nbsp;

[jlokanis]

Yes, I am seeing a slow memory leak, but I do not know if it is coming from the DS open-close.&nbsp; I read the workaround.&nbsp; What do you mean by 'ActiveX' VIs?&nbsp; Are the standard DS VIs using ActiveX or are there other VIs for DS that use ActiveX?The workaround states to open, do all your writes and then close.&nbsp; What if this operation is used many times in many places in an app that is supposed to run for many weeks?&nbsp; Am I supposed to cache the open ref and then pass it around?&nbsp; Is the leak coming from the open command or is the close simply not cleaning up properly?&nbsp; Does it matter what kind of write or read operation I do (I only use lookout calls to a remote cFP unit).&nbsp; What if this VI is reentrant and can be called by multiple threads simutaneously?&nbsp;Pleae provide a lot more detail on this issue and look at my VI.&nbsp;thanks,&nbsp;-John

[Karunya_R]

Hi John,&nbsp;I took a look at your VI and it does use DataSocket Active X.&nbsp; An example of a datasocket ActiveX vi is Browse to OPC item.vi in the shipping examples.&nbsp;&nbsp;I tried to run your VI but it looks like you are using an internal IP
address in your VI (which of course I wouldn't have access to). After how long to do you see your memory leak? Have you tried to use the VI profile window to track memory use for your VI. <a href="http://digital.ni.com/public.nsf/allkb/9515BF080191A32086256D670069AB68" target="_blank">This</a> knowledgebase has instructions on it.&nbsp; &nbsp; Thanks,

[jlokanis]

My VI just writes to a DIO output on a DIO card in a cFP unit that has the ethernet interface (no controller).&nbsp; Yes, this is a piece of HW in out lab.&nbsp; You could easily reproduce this by writting to a DIO card in your own cFP unit at NI.I do see a slow leak (over many days) in my application.&nbsp; I call this VI about 200 times a day.&nbsp;So, what you are telling me is the bug with DS will cause this VI to leak.&nbsp; Do you have any suggestions for how to work around this?&nbsp; The problem I have is many asyncronos threads are calling this VI so it has to be set to reentrant and therefore storing one global DS session and reusing it is not practical.&nbsp;