Exe not responding for 5 minutes on exit

[Ben]

Still shooting in the dark...

Are you repeatedly opening and closing anything?

every time we open and close a references etc. a small amount of memory is allocated to whatever it is that is opened. "closing" those references does not de-allocate the memory allocated for a that "something" but only marks it as "closed". Only when the application shuts down does that memory get released.

One question that would rule out that issues is "if the app runs longer, does it;

A) use more memory or

B) take longer to shutdown?

Ben

[ASTDan]

Hello,

I just Open my exe then close it right away and get the long close time.  I don't think I am opening and closing many things.  I am making that dynamic call but I am closing everything down like I want.

I might be quitting the application before I close a reference to a user event.  I made the change and sent it to my customer.  Will let you know.

I just got off the phone with my customer.  She found the exe is logging errors to a file.  She is sending it to me.  I have never heard of this.  Do you know if LabVIEW exe log errors?

Thanks

[Hooovahh]

So I've seen everything you are describing before.  The longer the application was up the longer it took to exit, and exiting meant increased memory leading up to the actual closing of the application (even though it became hidden immediately).  I looked into all sorts of things like releasing working memory and that just made things worst.  The task kill was my solution until I had more time to look into what was really happening.

In the end in my case it was due to a memory leak in the end of the G code.  References were being opened continually, and not being cleaned up, and the longer the app was open the longer references were being opened.  Only on a Close did the run-time engine try to finally clean all these things up, because the VI that opened the references closed, thereby allowing the VI references being opened to finally clean up.

Finding this was a pain.  I'd basically did a binary search.  Run the EXE, do nothing wait a set amount of time (6 hours?), close see how long it took to close.  Then disabled part of the application like the report generation portion, build the EXE, run it wait 6 hours, close see how long it took.  Repeat for many days...I also added the Performance Monitor to log various memory usage of my application looking for upward trends.  After searching and searching I finally found the cause in my case and it was using the Variant Probe XControl.  This XControl was in a VI that was for debugging but left in.  It just continually ate up memory but in a way that if the app was only open for a few minutes wouldn't be noticeable.  I'm betting you have a similar issue of memory being eaten up somewhere.  Since all these updates and memory tracking down I've had lots of good success.  Apps can run for many months, and respond quickly, no memory increase, and close quickly.  This has been in most versions of LabVIEW since 2015.

[wiebe@CARYA]

So you're saying that stopping the code doesn't release memory of all the references? Or was it data that was build up, even when the code was stopped and then restarted?

Shouldn't DETT detect that? I think that was used by OP.

The problem I'm having will make LabVIEW close very slow. The project itself closes pretty quickly. Shouldn't that close al references and data contained in the VIs?

Closing the getting started window take a bit longer then I'd expect. But the LabVIEW icon in the Windows toolbar just sits there forever...

[Hooovahh]

Sorry if I wasn't clear.  If a reference is opened in a VI, that reference stays open until it is either closed, or the VI that opened it becomes idle.  In my case references were being opened all time time and never explicitly being closed.  So when that VI finally went to idle, there were likely something on the order of 100,000 references that needed to be closed.  I'm guessing this is why it just took so long for it to exit. 

In my case the EXE behaved this way, and the source would behave this way if I performed a Quit on LabVIEW after stopping my application and doing cleanup properly.  I can't remember if it behaved this way when closing the project or not.  I was more interested in reproducing the issue and isolating it.  I had lots of code simulating execution of a test so that tests would continually be ran in case it had something to do with the execution of the sequence and not some overhead.

EDIT: Link to NI document just in case. 

---

 LabVIEW automatically closes a reference when the top-level VI that opened the reference goes idle, but if the application runs for extended periods of time, the effects of reference leaks gradually increase.

---

[ASTDan]

Hello,

This is the error file my customer sent to me.  This human readable file was generated in the AppData/local/temp It looks like every VI is bad.  I don't know how this can happen because the exe runs fine.

Anybody know what this means?

Thanks

[wiebe@CARYA]

The last debug output has something to do with the class mutation history. So a cleanup of the class mutation history might help.

The class mutation is used to flatten\unflatten class data, taking into account the class changes over time. If you don't do that, it's beneficial to clean class mutation for all classes every now and then. It increases load time of the project, and decreases file sizes.

See the end of this small thread.

Worth a try, no guarantees. It could be completely unrelated. The clear class mutation action itself is usually pretty harmless, but you should have SCC (or at least a decent backup system), so you can revert if things do go wrong.

[ASTDan]

I will give that a try.

Thanks