Memory Leak? (Update)

[markwysong]

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.

[Martin_Henz]

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:8nu0i8$dig$1@nnrp1.deja.com...
> 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.

[markwysong@my-deja.com]

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 <8nvscb$lue$10$1@news.t-online.com>,
"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:8nu0i8$dig$1@nnrp1.deja.com...
> > 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.

[CraigGraham]

Mail NI? Even though 6 is now out, I'd have thought they'd be under some
obligation to help you out with a bug inside 5- for customer relations and
moral reasons if not for legal reasons!

Speaking along such lines, most mainstream computer languages are open, in
the sense that anyone can write a compiler for it, and the language (and the
saleability of those skilled in the language) can't be wiped off the map in
the event of a single manufacturer moving away from it. Are my suspicions
correct that if NI decide to pull the plug, all our experience becomes
essentially worthless? Is the G language copyright or patented or whatever
as well as the Labview application? As Labview moves more and more to being
an all purpose environment rather than just fo
r quick lab hardware control,
I can see this issue becoming more significant.

wrote in message
news:8o0pi5$la1$1@nnrp1.deja.com...
> 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

[markwysong]

I have mailed NI (today). We'll see what the solution is. My hope is
that you are correct, I could get a good version of the .dll. You bring
up an interesting point, though. While I don't think that NI will move
away from LabVIEW, it does introduce the thought that since it is moving
in a direction that makes it suitable for more than just lab
applications, if it disappears, does that make us useless? (Maybe I
should learn FORTRAN or COBOL) 😉

I'll keep you posted on what NI decides.


Mark

In article <8o14gi$tjr$1@sponge.lancs.ac.uk>,
"Craig Graham" wrote:
> Mail NI? Even though 6 is now out, I'd have thought they'd be under
some
> obligation to help you out with a bug inside 5- for customer
relations
and
> moral reasons if not for legal reasons!
>
> Speaking along such lines, most mainstream computer languages are
open, in
> the sense that anyone can write a compiler for it, and the language
(and the
> saleability of those skilled in the language) can't be wiped off the
map in
> the event of a single manufacturer moving away from it. Are my
suspicions
> correct that if NI decide to pull the plug, all our experience becomes
> essentially worthless? Is the G language copyright or patented or
whatever
> as well as the Labview application? As Labview moves more and more to
being
> an all purpose environment rather than just for quick lab hardware
control,
> I can see this issue becoming more significant.
>
> wrote in message
> news:8o0pi5$la1$1@nnrp1.deja.com...
> > 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
>
>


Sent v
ia Deja.com http://www.deja.com/
Before you buy.