Memory leak only when compiled

[Anonymous]

I have a memory leak problem with an application built under LabVIEW
6.0.2. I have found that the source of the problem lies within a loop
of code that runs every minute. It reads numbers from a remote data
socket server and appends the numbers to 75 text files using the Write
Characters to File.vi. The code also does some calculations with
these numbers using formula nodes and discrete multiplication,
addition and subtraction, but it does little else and does not contain
any of the usual suspects for memory leaks. This code will run
happily in LabVIEW for days, but when I try to build the application
and run it, the memory it uses and the number of handles shown in the
windows task manager gradually increase for 12 to 18 hours until
the
app stops responding.

Is there a difference in how the VI and the compiled code access data
sockets or files that might contribute to this problem? I have tried
compiling this on two computers and running it on a few others, so I
don't think that the problem is unique to the run time engine or
compiler on my computer. I don't want to tie up LabVIEW to log this
data and I can't tolerate interruptions in the data collection. In
addition, several other computers need intermittent access to this
data, so I don't want to get rid of the data socket communication.
Where can I turn when the compiled app does not work?

[Wiebe@CARYA]

Hi,

Can you send the VI responsible?

Regards,

Wiebe.

"Matt@MTL" wrote in message
news:5065000000080000002CC00000-1075935269000@exchange.ni.com...
> I have a memory leak problem with an application built under LabVIEW
> 6.0.2. I have found that the source of the problem lies within a loop
> of code that runs every minute. It reads numbers from a remote data
> socket server and appends the numbers to 75 text files using the Write
> Characters to File.vi. The code also does some calculations with
> these numbers using formula nodes and discrete multiplication,
> addition and subtraction, but it does little else and does not contain
> any of the usual suspects for memory leaks. This code will run
> happily in LabVIEW for days, but when I try to bu
ild the application
> and run it, the memory it uses and the number of handles shown in the
> windows task manager gradually increase for 12 to 18 hours until the
> app stops responding.
>
> Is there a difference in how the VI and the compiled code access data
> sockets or files that might contribute to this problem? I have tried
> compiling this on two computers and running it on a few others, so I
> don't think that the problem is unique to the run time engine or
> compiler on my computer. I don't want to tie up LabVIEW to log this
> data and I can't tolerate interruptions in the data collection. In
> addition, several other computers need intermittent access to this
> data, so I don't want to get rid of the data socket communication.
> Where can I turn when the compiled app does not work?

[Anonymous]

Possible hint;

Somewhere around LV 6.0.2 there was an "issue" with the "delete from
array" function where the dleted element had to be wired to SOMETHING
or memory would leak.

Just wiring it to the edge of a structure was enough to avoid the
leak.

If not using "delete from array", then disregard this answer.

Trying to help,

Ben




href="http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=261&HRedirected=True&HUserId...

Certified LabVIEW Developer
www.DSAutomation.com

[Randall_T]

"Matt@MTL" wrote in message news:<5065000000080000002CC00000-1075935269000@exchange.ni.com>...
> I have a memory leak problem with an application built under LabVIEW
> 6.0.2. I have found that the source of the problem lies within a loop
> of code that runs every minute. It reads numbers from a remote data
> socket server and appends the numbers to 75 text files using the Write
> Characters to File.vi. The code also does some calculations with
> these numbers using formula nodes and discrete multiplication,
> addition and subtraction, but it does little else and does not contain
> any of the usual suspects for memory leaks. This code will run
> happily in LabVIEW for days, but when I try to build the application
> and run it, the memory
it uses and the number of handles shown in the
> windows task manager gradually increase for 12 to 18 hours until the
> app stops responding.
>
> Is there a difference in how the VI and the compiled code access data
> sockets or files that might contribute to this problem? I have tried
> compiling this on two computers and running it on a few others, so I
> don't think that the problem is unique to the run time engine or
> compiler on my computer. I don't want to tie up LabVIEW to log this
> data and I can't tolerate interruptions in the data collection. In
> addition, several other computers need intermittent access to this
> data, so I don't want to get rid of the data socket communication.
> Where can I turn when the compiled app does not work?

Matt,
Check your file I/O operation. Chances are you are creating a new file reference
each time you are opening the file without closing the previous reference.
Make sure you have a close for each open.

Hope this works for you.
Randall

[Matt@MTL]

Thanks Randall, the problem was related to file I/O. I found a subVI that was using converted LabVIEW 5.1 versions of the configuration file VIs with references opened with the LabVIEW 6 Open.vi. The reference was passed back out and closed with with the LabVIEW 6 close, but apparently there is some incompatibility here that only shows up when the application is compiled.

Matt