Application locking up at Call by Reference

[tommiejb]

We are seeing our application lock up occasionally at a VI Server Call By Reference node. The VI acts like it is waiting for subVI called to execute, but the subVI acts like it never got the message to execute. We've seen this at a number of VIs that call subVIs by reference. In some cases we are using strickly typed VI references, and in other cases we are not. We've seen the code lock up in both. Has anyone else seen this type of behavior?

We are running LabVIEW 7.0, Windows XP, and TestStand 3.0.

Also, I noticed that in a couple of places, the reference isn't explicitly closed. Since these VIs are only a small part of the application, not called very often, would that cause much of a problem (memory or otherwise)?

[SAS]

Sorry for sending an empty reply previously!

I have also faced the same problem in our customized operator interface. In the code, we have used both user events and event callbacks. I did various trials and got the code working without hanging by removing all the user events.

Please refer the following topics: "TestStand Event 13 - UIMsg_StartInteractiveExecution is not captured by LV Operator Interface " and "TestStand hang, Execution with Event-Callback-VI "

Thanks

Sasi

[tommiejb]

SAS,

The problems described by TPoint in the thread "TestStand hang, Execution with Event-Callback-VI " sound familiar.  Our code locks up at the "Run VI" Method (I've enclosed a screen capture of the VI where it locks up), and once it does, you can't open any VIs from Explorer.  You can still open VIs from within LabVIEW.  My main problem, though, is trying to get it to happen in a small application, and getting it to repeat more frequently.  Right now, we can go through 200 test runs before it happens.  Not enough to stop production, but enough to cut into our yields.  Unfortunately, it also makes it very hard to diagnose.  On our development system, it takes about 4 days to get through 200 runs.  So what I'm getting at is, if you can post an example of where you saw the problem, may that would help me put together an example of my problem.

We don't use Events, we use polling.  We are also using LabVIEW 7.0, and I see that TPoint was using LV 7.1, so I couldn't open that example.  If there are other screen shots that you think would be helpful, let me know.  The Operator Interface is huge (its inherited code, I wish I had the time to rewrite it), so I can't post the whole thing, but if there are specific routines (such as the polling routine) that you'd like to see, I could post that.

Thanks,

Tom

[Caroline Bright]

Hi Tom,

I believe we have spoken on the phone a few times about this issue so  i wanted to touch base with you again.  We had discussed that you found a race condition in your VIs at some point.  I would continue to investigate to try and find these race conditions.  Also, try to take out as much of the "extra" code in the vi.  If we can get the example of the error down to a small vi that can be run in a loop continuously, it will be much easier to find what may be causing the strange behavior.

[tommiejb]

Caroline,

We are still working on putting together a small example that demonstrates the problem.  With an Operator Interface that has over 200 VIs and a test app that has over 400 VIs, we are struggling to determine which are the relevant VIs that are causing the problem.  I believe the issue is a clash between TestStand calls and Call By Reference calls, so we are pursuing this path.

In the meantime, the discussion thread "TestStand hang, Execution with Event-Callback-VI" appears to be the same problem.  This thread just seemed to die out without a resolution.  Since this thread does contain an example VI that demonstrates the problem, could you look into what the root cause is for this hang?  As best as I could tell, the "solution" was to make sure that the Call By Reference happens serially with the TestStand calls, rather than in parallel, but there didn't seem to be an answer as to why it was happening in the first place.  Since it is not practical for me to change the code to prevent code from running in parallel, I need to know the root cause.

Thanks,

Tom

[Caroline Bright]

Hi Tom,

I talked with the developer who was responding on the "TestStand hang, Execution with Event-Callback-VI" discussion forum post.  If you read towards the end of the post (replies 11-13) they realized that the hang that they were able to reproduce only came when the pollingenabled property was inside a loop.  This resulted in the property being set over and over again.  This resulted in windows messages being created and destroyed over and over again as well.  This would spawn windows messages that needed to be handled.  But eventually, it would get stuck in a thread that wouldnt process the messages.  For example thread A tells thread B to do something.  Thread B posts a message and waits for it to be processed.  However, thread A is blocking the message from ever being processed and thread B never returns.  In this customer's situation this was being caused by setting the polling enabled to false within a loop.

Now, this does not mean that this is not your issue but I just dont have enough information to tell you yes or no.  This is why it is important to break up your program into a smaller example that demonstrates the behavior.  Try taking out small sections at a time to see if you continue to see the same behavior.  I know this is a tedious process but it is difficult to diagnose the behavior without being able to reproduce the issue here.

[SAS]

Hi Tom,

I don’t have any specific solution! I can explain how I could able to debug my code. As i know where the code was hanging, I started simplifying the code one case after other. I have also logged various events happening (in my case - it was needed) to know exactly after what event the hanging occurs.

You can also do the same - because i believe that unless we reduce the code and explain the issue more specifically, we may not able to find a solution.

Thanks

Sasi