Resetting VI: Arrggghhh!

[cowen]

Hi Guys,

I apologise if this is repeated somewhere...

I have an application that runs several external re-entrant test steps dynamically (external being - outside of the EXE). This is pretty typical I think.

This worked very reliably with LV8.2.1 and there was never a problem. We have recently compiled with LV2011 and here is where the fun starts. During normal execution, we occasionally see a message 'Resetting VI: <step name>'. Debugging is very difficult. The message appears randomly. Occasionally once a week, occasionally once a month!

After some reading I found many suggestions that this could be attributed to VI references not being closed. However, having checked the code repeatedly, I am confident that all references are being closed. Currently I launch the VI's with the 'Run VI' invoke node. Wait Until Done = False, Auto dispose ref= False.

I am wondering whether the problem would be solved simply by allowing LV to manage reference disposal??

I doubt you can tell me the problem, but any ideas of what to look at would be welcomed. I have checked everything I can think of.

[asbo]

Not that I necessarily think that it's related, but why aren't you using auto dispose ref?

Personally, I've only ever seen the Resetting dialog when I really botch something and I'm trying to close a hung, running VI. That said, LV8.2.1 to LV2011 is a huge jump, it could be possible that something upgraded incorrectly. If you haven't inspect everywhere you touch those references. You might toy with the Start Asynchronous Call node that's now available to you, see if it eliminates your issue.

[crelf]

...we occasionally see a message 'Resetting VI: <step name>'. Debugging is very difficult.

And what's the real impact? Does it show up for a second and then close itself? Does it show up for 5 minutes? Forever?

[Aristos Queue]

The Infinite Reset Of Death dialog (that's what I call it anyway) almost never comes back in my experience, even though, as far as I can tell, it is always at least theoretically possible for it to come back. It's ancient code, deep in the execution system, but several years ago I went spelunking to try to figure it out. Seems to be -- and this is me not really understanding -- a tug of war in your code between a VI wanting to shut down and itself saying "Actually, wait, I'm not done with myself yet" and if the one process could ever get just a little more thread time, it could actually shut down. LV gets thoroughly hung because the UI thread is involved in the tug of war. That may be completely wrong. If anyone else chimes in claiming to know better, go with their answer. Regardless of the cause, I have waited multiple hours on that dialog, just to see, and only once of multiple tries did it unstick, and that happened after about 10 minutes. I treat it as a crash, myself, and if it occurs, I re architect to avoid it, though, as I say, I'm not really sure what causes it. What this means in practice is I change stuff until it goes away.

[cowen]

OK, to answer questions and give some more information.

Once the resetting VI message appears, its game over. Do not pass Go, do not collect $200 and in this case, since production completely stops, go straight to jail (ok the job centre - but you get what I mean).

The reason for managing the references ourselves was from some very early experiences with LV6.1 where it appeared that LV was not releasing references. This experience from many years ago has caused me to be a little cautious and really ensure references where being closed and memory was released. I am sure LV2011 is a phenomenal jump though with regard to how things like this are managed and this is just unnecessary paranoia.

So as per my post, I modified the code so that LabVIEW now handles closing the step VI references itself. Hey presto, the resetting message has not been seen since. Previously the error occurred every 4-6 hours. Now after 30 hours, no problem.

So I have a solution, but to be honest, I don't fully understand why the problem existed, but production runs reliably again.

Thanks as ever to everyone for their comments and support. ;-)

[crelf]

...several years ago I went spelunking...

That's a great term for some of the code I have to deal with occasionally.

So as per my post, I modified the code so that LabVIEW now handles closing the step VI references itself. Hey presto, the resetting message has not been seen since. Previously the error occurred every 4-6 hours. Now after 30 hours, no problem.

I'm not surprised. I mean, LabVIEW shouldn't get into the tub-of-war that AQ descriobes above, but I'm not surprised that not closing refenences put you there.

Glad to hear you've got a work around!

[Wire Warrior]

Sounds like a job for DETT....Desktop Execution Trace Toolkit.

[cowen]

Grrrrrrrrr - here we go again.

So allowing LV to close the references means I no longer see the resetting VI message. I think this message was appearing when I was trying to close the reference to the test step. Mostly the references were being closed normally, but occasionally, it was not possible. However, now the application runs reliably, I don't see the resetting VI message, but when I try to close the application, it hangs. Preseumeably because LV also was unable to release the references to some steps and the application needs this memory released before closing..

So in short, I think I have masked the problem and not fixed it and actually I really need to find the underlying cause. Surely this is a LV issue and not my application since now, LV should be releasing all references. The steps have completed there actions as the sequence continues.

Any ideas?

[cowen]

Sorry, an extra comment. I have just found the following paragraph....

"One parameter that you probably want to pass the clone is the new clone’s own VI reference — the one created using the Open VI Reference function. This is a very special reference, because (unlike an implicit VI Reference ) closing it will cause the clone to stop executing immediately — killing the VI dead in its tracks. Generally, you will want to pass this to the clone, so that the clone can be in charge of closing it, when it completes execution."

Found here: http://thinkinging.com/2007/03/29/reentrant-vi-clone-name/

OK this is an old document and discusses LV8.2.1 mainly, but does anyone do this? Do you really pass a clone VI its own reference as a parameter and then set the VI to close its own reference?

[shoneill]

@cowen,

this I didn't know. I've certainly never passed a clone it's own reference.... Seems really counter-intuitive.

[Aristos Queue]

this I didn't know. I've certainly never passed a clone it's own reference.... Seems really counter-intuitive.

The only reason to do that is when you're going to let the clone go free running and shut itself down. We created the Async Call By Reference node to cover this use case more intuitively.