09-12-2017 10:08 AM
Basic info that can be skipped:
I have an application (test sequencer) that uses 2 types of reference and I seem to have a memory leak. It already uses ~700M when I call the test file and another large chunk when internal monitoring is active to save some data to file at the end. It ran out of memory throughout the weekend on a 32bit Windows. It was 1.4G in memory according to the task when I got to it on the following Monday (I expected to see 2G).
I wonder if the Main application is still considering as open reference when the windows are closed through user manipulation or VIs being self-closed.
First Asynchronous Type: Debugging windows
2 types:
Running VI: A complete VI with JKI State machine
Static Front Panel with indicators
Second Asynchronous Type: Multiple Clones
Thanks
09-12-2017 11:09 AM
I don't know if it contributes to your problem, but my first advice is not to rely on "Abort VI" calls. Make yourself a cleaner, more controlled shutdown mechanism.
Use of "Abort VI" can leave the async vi's in a weird state. It seems plausible to me that when you use it on async clones, those clones may not get cleaned up properly, and you don't know it because the next launch creates a distinct instance of it that works.
-Kevin P
09-12-2017 12:11 PM
09-12-2017 03:33 PM
I stopped using VI Server and the Run VI Method as soon as I learned about Start Asynchronous Call, which seems (to me) much cleaner and easier to manage.
Bob Schor
09-12-2017 05:16 PM - edited 09-12-2017 05:17 PM
@Kevin_Price wrote:
I don't know if it contributes to your problem, but my first advice is not to rely on "Abort VI" calls. Make yourself a cleaner, more controlled shutdown mechanism.
Use of "Abort VI" can leave the async vi's in a weird state. It seems plausible to me that when you use it on async clones, those clones may not get cleaned up properly, and you don't know it because the next launch creates a distinct instance of it that works.
-Kevin P
Thanks, that makes sense, however the white papers shows it with Abort VI 😛
http://digital.ni.com/public.nsf/allkb/68128403FC24FB6E86257211007F1104
What would be required to have a cleaner & controlled close?
09-12-2017 05:18 PM - edited 09-12-2017 05:18 PM
@ben64 wrote:
If you're licensed for the Desktop Trace Execution Toolkit you should try running it (Tools -> Profile -> Trace Execution...).
Ben64
I don't get much information out of Desktop Trace Execution Toolkit when I use it. I'm using LV2011.
09-12-2017 05:24 PM
@Bob_Schor wrote:
I stopped using VI Server and the Run VI Method as soon as I learned about Start Asynchronous Call, which seems (to me) much cleaner and easier to manage.
Bob Schor
I did try a variety of methods, which also eventually evolved into the "Clones" code. I had issues getting the Start Asynchronous Call or maybe I just abandoned it faster than I should as the VI Server was working before I got the "Start Asynchronous Call" code working.
09-13-2017 09:32 AM
That knowledgebase link does indeed use "Abort VI", but there is some not-entirely-obvious context to the question. It's specifically for a case where a *user* needs to stop a vi when the normal methods that are provided in a GUI have been taken away.
A common method used to send a "shutdown" message to async code is to use a Notifier. The async code must be programmed to catch this notification, then proceed to do an orderly shutdown. The nice thing about using a Notifier is that it can be used as a 1-to-many mechanism to signal a shutdown to *all* the async processes at once.
It will be a big help to switch over to using Start Async Call as others have advised, then you can just wire in the Notifer ref to the async code modules.
-Kevin P
10-12-2017 10:09 AM
Is there another way to force clear VIs in memory?
I tried plugging in a "Request Deallocation" within the main software and the clones, can't see any difference in the "Profile Performance and Memory" or the Task Manager.
10-12-2017 11:03 AM
I have a suggestion for you. Create a small, simple Project that involves starting and stopping a Clone. Make it do something straight-forward, such as "Generate a random number once a second". Put enough into it to clearly illustrate the problem that you are having (as without "code to examine and test", it is difficult to really understand the issue you are having).
When you are done, compress the folder with the Project and attach the resulting .zip file. Please develop in something earlier than 2017 (as not everyone has installed this version, I among them).
I, for one, will be happy to look at and try to understand the issues you are having. I (and probably others) may also try to modify your example using Start Asynchronous Call , as we have suggested, and see if that does the trick. If nothing else, this should give us a much clearer picture of the problem(s) you are having with your code.
Bob Schor