Memory Leak? (Update)

Question

Thanks for all the responses for this problem. Here is what I've come
up with so far. I believe I have found the culprit.
1) First, I used the LabVIEW VI profiler with memory tracking enabled.
This didn't show what VI was hogging the memory, so it didn't help. It
reported only 10M of memory was being used, when Windows NT reported
110M in use by LabVIEW.
2) VI references had been mentioned as the possible culprit if the
references had not been closed. I then opened a VI reference at the
beginning of the program, used these references throughout the loop, and
then closed them at the end of the loop. Result: still had a memory
leak.
3) After some troubleshooting, I started deleting some sub-VIs out of
my program to see when
the memory was freed. I thought I could isolate
which VI was hogging the memory. This seemed to have worked, because
I've done it twice, deleting different VIs up to a point, and when I
delete one of them out of the diagram, the memory is freed. This is
what I'll explain below.
Every iteration of the loop, the front panel is converted to a .png file
and saved to the drive for output across the network to any browser
which has connected. Using the LabVIEW/vi.lib/utility/printvi.llb/Get
Panel Image.VI, the front panel can be changed into a .png format. The
next step is where the problem lies. A Java applet is looking for a png
file to download to a browser when a request is made. Therefore, the
panel image which has just been made needs to be saved to a file. The
Graphics & Sound -> Graphics Formats -> Write PNG file.VI is used for
this. This is the VI which is causing the problem. Upon looking at the
VI, it just calls a CIN. Therefore, I'm not sure how to find out why it
is
hogging the memory. If I delete this VI, and I don't save the front
panel to a png file (but I do convert it to png format), I don't have
the memory leak.
Any ideas?
Mark
Sent via Deja.com http://www.deja.com/
Before you buy.

Answer 1

I wish I could update to LV 6i, but I can't now. I'm stuck with 5.1.1
for now. I don't know how I could "legally" get the .dll and png write
VI from 6.
Mark
In article <[email protected]>,
"news.t-online.de" wrote:
> Hi Mark,
>
> you are right. It looks like lvpng.dll is causing the problem.
>
> Are you able to switch to LabVIEW6? The lvpng.dll has been changed
> and I didn't see the memory leak here. You can also try to use only
the
> Write PNG File.VI and/or lvpng.dll shipped with labview 6 instead of
> porting the complete application to labview 6.
>
> Martin
>
> --
> Martin Henz Systemtechnik
> Dipl. Ing. (FH) Martin Henz
> Walchensee Str. 3
> 70378 Stuttgart
> Tel. ++49-711-5302605
> Fax ++49-711-5058649
> http://www.mhst.de
> schrieb im Newsbeitrag
news:[email protected]...
> > Thanks for all the responses for this problem. Here is what I've
come
> > up with so far. I believe I have found the culprit.
> >
> > 1) First, I used the LabVIEW VI profiler with memory tracking
enabled.
> > This didn't show what VI was hogging the memory, so it didn't help.
It
> > reported only 10M of memory was being used, when Windows NT reported
> > 110M in use by LabVIEW.
> >
> > 2) VI references had been mentioned as the possible culprit if the
> > references had not been closed. I then opened a VI reference at the
> > beginning of the program, used these references throughout the loop,
and
> > then closed them at the end of the loop. Result: still had a memory
> > leak.
> >
> > 3) After some troubleshooting, I started deleting some sub-VIs out
of
> > my program to see when the memory was freed. I thought I could
isolate
> > which VI was hogging the memory. This seemed to have worked,
because
> > I've done it twice, deleting different VIs up to a point, and when I
> > delete one of them out of the diagram, the memory is freed. This is
> > what I'll explain below.
> >
> > Every iteration of the loop, the front panel is converted to a .png
file
> > and saved to the drive for output across the network to any browser
> > which has connected. Using the
LabVIEW/vi.lib/utility/printvi.llb/Get
> > Panel Image.VI, the front panel can be changed into a .png format.
The
> > next step is where the problem lies. A Java applet is looking for a
png
> > file to download to a browser when a request is made. Therefore,
the
> > panel image which has just been made needs to be saved to a file.
The
> > Graphics & Sound -> Graphics Formats -> Write PNG file.VI is used
for
> > this. This is the VI which is causing the problem. Upon looking at
the
> > VI, it just calls a CIN. Therefore, I'm not sure how to find out
why it
> > is hogging the memory. If I delete this VI, and I don't save the
front
> > panel to a png file (but I do convert it to png format), I don't
have
> > the memory leak.
> >
> > Any ideas?
> >
> > Mark
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.