Program runs fine then takes a long time to close

[Phil_]

Hi Everyone,

I have written a mid sized application, which is running fine until it comes to closing, then it takes an age to close. If it has only been running for a short time it closes fine, but after some time running it takes longer and longer to close. Until you try to close, it remains fully responsive and performing well.

I have heard the phrase 'memory leak' banded around, but am not 100% sure how I would have created one of these. I am also looking into my queues accidentally getting too big.

If you had this a problem like this, where would you look first?

I could do with some advice around common places that this kind of thing happens.

I don't really want to post my whole application on here, but it includes:

• Multiple loop event based producer consumer
• Camera acquisisition and image processing
• DAQ for some simple digital I/O
• Reading and writing to text and image files
• Error handling
• Compiled as an executable
• No local variable abuse

Any advice would be appreciated.

Thanks.

[P@Anand]

Since you are using multiple loops when you try to stop it if any one loop is waiting inside then it may appear freezing without response. Check the loops exection time and try to keep a global stop in all the loop so that it won't be left out waiting for anything else.

[crossrulz]

Any building of arrays?  If those get large, the application can start to get sluggish.

P@Anand is probably on the right track.  Make sure you check your closing operations and make sure a loop isn't left sitting there for a long time.

I have also seen file handling take a lot of time to delete temporary files or close large files.

[mjochinsen]

I like to add a "stopping..." indicator. I add it to all parallel loops.

It does not follow Labview best practices but it can be useful sometime or it can be a tool for debbuging.

[RavensFan]

I don't think that helps with debugging.  It may or may not be a brute force way to force other loops to stop, but if the loop is hung up for some other reason, your "stopping" variable isn't going to help.

For debugging, put a boolean indicator outside of each loop with the stop wire tunneling out of the loop to it.  Give each indicator a name that represents the loop is is connected to.  When your program starts, write a False to local variables or property nodes of each indicator.  Now when your program ends, the loops that have actually stopped will have their boolean indicator light up.  Those loops that are stuck will still have the boolean light unlit.

[Phil_]

Thanks for the ideas guys.

I thought I would leave a reply to my own problem for the benefit of future forum searchers:

Debugging with the 'loop exit indicators' was useful, I also took it a step further with a timer FGV as time to quit increasing with use was the issue.

The problem seemes to go away with an 'enqueue at opposite end' VI to close my error handling loop. I decided I didn't mind about errors at the end of the program, and they could be forgotten about rather than displayed.

Still not 100% sure why it helped, as reading the documentation seemed to infer that this option didnt apply to how my code is written, but I wired True the 'Force Destroy' input on the Release Queue vi for one of my queues.

A colleague has also had a simmilar problem, and was creating lots of database references and fogetting to close them.