LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Memory leak with FP closed

Well this is an odd one I must say.

I have an application where I would like the front panel to disappear at the user's discretion so it's not in the way while it's processing information in the background.  To process the information I have a custom DLL and to check the progress of the custom DLL, I have a routine that I can call that will return the status.  So the information processor is called and it just runs in the background, and then the status routine is called in a parallel loop until the status routine determines that the processing is finished.  When the status routine says it's done, the parallel loop exits and another routine sets a flag for the processor to exit (so everything quits).

In order to make the DLL calls work right as far as execution sequencing, they are called as re-entrant.  I stumbled across that orginally because it was locking things up when I was trying to call them in parallel.

I have no memory leaks in the external DLL calls and this is verifiable by running the processing routine indefinitely while checking the status indefinitely.  The problem is when I open a VI reference to the main VI then make it's front panel not visible.  At that point, memory usage starts increasing by 400k/sec (which is larger than the entire DLL).  It will eventually just crash the system.  If I set the front panel to be closed on a timer (for several seconds say), the memory usage will increase for that amount of time and then stop once the FP is opened again.

I know this is really difficult without having some code to look at but it would be really hard for me to dumb down the code to get the problem in a simple set of VI's to look at.  I'm wondering however if the reentrant DLL calls are having some weird interaction with windows since I'm guessing at a lower level, the application's window handle is invalidated when the front panel is closed.  I'm wondering if the reentrant DLL status call is having new memory allocated for it every time it is called in the status loop.  I just can't figure out how that has anything to do with the front panel being closed though.

Any suggestions on things to try or look at?
0 Kudos
Message 1 of 3
(2,726 Views)
Well after tweaking around, running the DLL calls in the UI thread instead of as re-entrant fixes the massive memory leak.  I can't think of a good reason why that isn't a bug, but whatever.  Perhaps it's not crashing the program now when running in the UI Thread since each DLL call is actually in it's own re-entrant VI wrapper.  Hmmm...
0 Kudos
Message 2 of 3
(2,721 Views)
Hi
basic question why don't you just minimise window ?

Thus the operator can do what ever while the program runs in background!

There is also the hide window vi if you wish to hidden the main menu whilst
operating on sub menu routine.

Chow
xseadog
0 Kudos
Message 3 of 3
(2,717 Views)