Jump to content

Application Task Kill on Exit?


Recommended Posts

So lets say I have a large application, lets pretend it is a 50MB EXE (it's not we are exaggerating).  I run this EXE and it runs for thousands of hours, then I close it.  When I close it all of the "Actors" run their own cleanup, and then the UI is hidden, then I call the Quit LabVIEW primitive.  If I look at the task manager the program still runs for some time after calling the Quit function but eventually leaves the task manager list.

 

I have seen in rare occasions (where I was messing with memory in ways I shouldn't) that caused the quit function to take up to a minute to actually exit.  What does this quit primitive do?  Why does quitting take longer than it should?  As a test I replaced the Quit LabVIEW, with a task kill operation on the EXE name.  Now when I hit the close button my application does the clean up on each Actor as it should, and then kills the program.  This operation now feels instant.

 

So is there something wrong with killing my program my way, after all logs have been closed, and hardware sessions closed?

 

EDIT: Okay so a search with Killing LabVIEW brought up this work around for killing an Actor based EXE.  So does this mean there is nothing wrong with killing other LabVIEW EXEs using this method?

Edited by hooovahh
Link to comment

What initially (because these are what have bit me) comes to mind is:

- Do you still have any code running at all that could take that long to terminate?

- How much memory are you using? How much of the memory is swapped out?

Link to comment

Well. Ever since LV2010 I've noticed that even the IDE takes forever to shut down. I have assumed (rightly or wrongly) that it is something to do with making sure the run-time exits elegantly, so the implications of a task-kill may be subtle and/or horrendous in some unknown scenario (DAQ config?).

 

Suffice to say. NI have done something during the shut-down process that has increased the duration significantly. I would compare your software with one that has been compiled in 2009. I would expect it to exit far more promptly if it is down to the NI environment.

Link to comment
What initially (because these are what have bit me) comes to mind is:

- Do you still have any code running at all that could take that long to terminate?

- How much memory are you using? How much of the memory is swapped out?

There is nothing running, after all code has stopped executing, and Actors have have performed their cleanup and then I call the Quit.  As for memory swapping out.  This is what can be used to show the biggest time in shut down.  If I force LabVIEW to release the working set of memory during normal execution, then Quit will take much longer to stop the EXE.  Now this is something I don't do regularly I just noticed it made it worst.  Even so why should this matter all my VIs are done running, when I say Quit why should it take a long time even if I did screwy things with memory.

 

 

I've run into this issue too (I don't have a fix for you).  I even take it a step further and close the front panel immediately, even without waiting for the loops to close.

That's fine and all but the EXE is still running.  I have the INI key of allowmultipleexecutions (it might be slightly different) set to FALSE, so if I exit (which just hides the UI) I can't restart the application until the last run is really done, which again may take a while.

 

 

Well. Ever since LV2010 I've noticed that even the IDE takes forever to shut down. I have assumed (rightly or wrongly) that it is something to do with making sure the run-time exits elegantly, so the implications of a task-kill may be subtle and/or horrendous in some unknown scenario (DAQ config?).

 

Suffice to say. NI have done something during the shut-down process that has increased the duration significantly. I would compare your software with one that has been compiled in 2009. I would expect it to exit far more promptly if it is down to the NI environment.

I also noticed longer shutdown time in newer versions.  But what could the run time engine be doing that is so important, where killing it would be bad if all the things I care about are closed out properly?  The problem with this question is no one but NI has a real answer, or could suggest why I shouldn't just kill it.

Link to comment
There is nothing running, after all code has stopped executing, and Actors have have performed their cleanup and then I call the Quit.  As for memory swapping out.  This is what can be used to show the biggest time in shut down.  If I force LabVIEW to release the working set of memory during normal execution, then Quit will take much longer to stop the EXE.  Now this is something I don't do regularly I just noticed it made it worst.  Even so why should this matter all my VIs are done running, when I say Quit why should it take a long time even if I did screwy things with memory.

What has bit me before is with running code are VIs that are "fire and forget" that I've forgotten about (particularly clones of VIs). All the VIs have stopped executing, except the dynamically called.

 

If you're using a lot of memory that has swapped out, then Windows (I'm assuming you're using Windows) has to swap it back in to physical memory to release it. This can take a Very Long Time. You can see it happening in Task Manager/Resource Monitor.

Link to comment

I can't say I use the quit/exit LabVIEW primitive anymore, but I do have 50 MB executables which can take a long time to shut down. This application can be called upon to manage data sets hundreds of GB in size resulting with a memory footprint of a few GB for tracking things like indices and caches.

 

I've observed this application take a minute to unload. I can watch the task manager tick down the memory footprint at a rate of about 100 MB/s as things get cleaned up. This is on my workstation grade system with 20 GB of RAM for an application that takes perhaps 1-4 GB of memory depending on data load. Large analyses on resource starved systems can take several minutes to unwind if page files get involved.

 

To some extent I also think its related to the size of the VI hierarchy-- size as in number of VIs, not number of bytes. I've written very simple "quick and dirty" applications with perhaps 10 VIs which can chew up pretty impressive memory footprints if you point them at sufficiently sized data sets, and when terminating these applications are pretty snappy. By contrast the 50 MB application with a sizable hierarchy can still take 20 seconds to unload even if it has no real memory load beyond what is required to run the application. I expect just as there's overhead involved with opening each VI when starting the application, there's something going on with each VI when terminating.

Link to comment
I don't think I have ever used 'Kill LabVIEW' in any executable the last 5 years. Why did you have to resort to it?

 

Ton

I don't have to resort to this I just don't know why it isn't immediate.  When I call quit I want the application out of memory within human noticeable speeds.  (say less than 500ms)

 

 

I can't say I use the quit/exit LabVIEW primitive anymore,

I'll add a case to my standard Quit if in RTE VI that has a kill as an option set to false by default.  If I see any issues this will be the first thing I change back.

Link to comment
I have to ask... how did you do this?

Using a modified version of this.

 

That VI specifically flushes out the working set memory for the application running named "SeqEdit.exe", it can be changed to any application name.  Using this on any application will cause the working set memory to drop very low but as soon as you need memory again it climbs back up as expected.  Using this code I've never actually seen any problems get fixed, just prolong the inevitable.

Link to comment

@rolfk

 

Regarding the LabVIEW stop / Car into wall situation.  I only use the LabVIEW stop in situations in development, when I know that all hardware and references I've opened, have been closed.  Similarly I am only talking about using kill as an option after all resources have been closed (File/DAQ/Queue/Events etc).

 

There is tons of details on how memory management works and I know very little.  I just don't know what kind of affect I will see (if any).  I've already released everything I care to release, and then tell Windows to remove the application from memory, terminating it and all of it's threads.  (I'm guessing it executes this Windows function)  What real issue could this cause?  Can anyone say doing this will cause an application to be corrupted?  Or for memory to not be released?

 

I'm not advocating this method, I just think it is a pretty simply way to make an application more Windows like (responsive close) and I have not seen any side effect yet.

Link to comment
@rolfk

 

Regarding the LabVIEW stop / Car into wall situation.  I only use the LabVIEW stop in situations in development, when I know that all hardware and references I've opened, have been closed.  Similarly I am only talking about using kill as an option after all resources have been closed (File/DAQ/Queue/Events etc).

 

There is tons of details on how memory management works and I know very little.  I just don't know what kind of affect I will see (if any).  I've already released everything I care to release, and then tell Windows to remove the application from memory, terminating it and all of it's threads.  (I'm guessing it executes this Windows function)  What real issue could this cause?  Can anyone say doing this will cause an application to be corrupted?  Or for memory to not be released?

 

I'm not advocating this method, I just think it is a pretty simply way to make an application more Windows like (responsive close) and I have not seen any side effect yet.

 

Well in principle when you kill an application the OS will take care about deallocating all the memory and handles that application has opened. However in practice it is possible that the OS is not able to track down every single resource that got allocated by the process. As far as memory is concerned I would not fret to much, since that is fairly easy for the OS to determine. Where it could get hairy is when your application used device drivers to open resources and one of them does not get closed properly. Since the actual allocation was in fact done by the device driver, the OS is not always able to determine on whose behalves that was done and such resources can easily remain open and lock up certain parts of the system until you restart the computer. It's theoretically also possible that such locked resources could do dangerous things to the integrity of the OS, to the point that it gets unstable even after a restart although that's not very likely.

 

Since you say that you have carefully made sure that all allocated resources like files, IO resources and handles and what else have been properly closed, it is most likely not going to destroy your computer in any way that could not be solved by fully restart it after a complete shutdown.

 

What would concern me however with such a solution is that you might end up making a tiny change to your application and unless you carefully test it to release all resources properly by disabling the kill option and making sure the application closes properly, no matter how long that may take, this small change could suddenly prevent a resource from being properly released. Since your application gets killed you may not notice this until your system gets unstable because of corrupted system files.

  • Like 1
Link to comment
  • 9 months later...
i have made 2 exe with labview and running about a week (win7), logging temp and posting it to google spreadsheet and now one exe is freezed so bad that even kill task dont kill it... what seems to be the problem? how can i kill it?

 

 

Normally, something like this would imply a memory leak. Use task manager to monitor your memory usage over a couple of hours; is it gradually increasing? Are you opening a reference repeatedly and not closing it? This can easily happened with "named queues" if you're not careful. 

Edited by GregFreeman
  • Like 1
Link to comment
i have made 2 exe with labview and running about a week (win7), logging temp and posting it to google spreadsheet and now one exe is freezed so bad that even kill task dont kill it.

If taskkill doesn't work you have bigger problems.  I'm guessing you aren't performing a taskkill but instead are politely asking the application to exit.  And if it isn't responding it won't exit.  In task manager go to the Processes tab, find your application and click End Process.  This is a taskkill and will remove the application from memory.  If you are on the Applications tab and try End Task this does not perform a taskkill but instead tries to close the application more gracefully and may take longer or not work at all.

 

Again as discussed in this thread task killing an application is not something to be taken lightly, and under the right circumstances may have no ill effects.  Generally this is only used when an application isn't responding and you don't want to reboot your computer to get back to a usable state.

Link to comment
"end process" didn`t do anything that is what i am talking about :)

 

If "End Process" doesn't work, your application is defininitly doing something VERY low level. Do you call some drivers that use kernel device driver somewhere? Except DAQmx of course, which definitely does have such drivers, but hasn't behaved like this on me so far. Other 3rd party vendor drivers however have done such things to me in the past. Unless your application is stuck in kernel space, "End Process" really ought to be able to kill the process cleanly.

Link to comment
  • 1 month later...

I know this is an old thread but I recently faced the exact same problem, where killing the labview task simply wouldn't work.  It was caused by a driver issue (USB-RS232 Prolilfic 2303).  In development  environment, the application would hang forever in a VISA Read and in the executable format, the application would just appear to freeze.  The only thing that would free the execution was to disconnect the USB device and then VISA Read would return an error.  Everything went away once we selected a different RS232 adapter (both MOXA Uport and Startech PCIe adapter solved the issue.)  We saw a few Blue Screen of Death over that development period with the Prolific IC.

 

Since your application seems to be calling a USB instrument, it is possible that its driver is also be the root cause of your issue.  If the instrument is working properly until you close your application, make sure that you call the proper functions to close the driver properly to allow it to stop executing.  If you also see some strange behaviors during execution, consider getting a better device/driver.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.