Weird LabVIEW crash

[Neil.Pate]

I wonder if anyone can help me with a problem I  am having right now.

My application has several free-running loops on the main VI (logging, UI etc etc).

I am getting strange crashes where some of the loops seem to hang, while others continue. For example a subVI will hang, and then the main UI seems to become unresponsive but the logging loop happily carries on. The logging loop does not have any UI component to it, so is it possible that I am somehow causing the UI threads to hang?

One of the free-running loops (shown in picture) updates an elapsed time counter on the main UI, this is how I know this particular bit of code is freezing. Any ideas why? 

I can't really post the rest of the code unfortunately.

[altenbach]

Are the crashes reproducible or random? 

Can you still switch to the diagram or is everything locked up? If you can, try enabling execution highlighting to see where there is still movement. Also place an indicator on the iteration terminal of all loops to better see what's happening.

Do you have any event structures?

Any communication with external devices?

[Neil.Pate]

The application is for an ATE, and when a test is running there is no user interaction. Unfortunately, all of the crashes seem to happen on a built application only, and then it may take 30 hours before a crash occurs, its quite random.

The rigs are not networked, so its quite tricky to do any kind of remote debugging. When a crash occurs the UI seems to lock pretty hard (dragging the windows on the screen results in them not being repainted as they drag). The OS (XP Pro) does not crash when this occurs.

I have three (supposedly identical) rigs constructed, and sometimes I get crashes, sometimes not.

There is quite a bit of external hardware, SCXI chassis, FPGA card, GPIB power supply, non-NI encoder card.There is an event structure on the main UI.

One thing I am doing, is using a lot of control references to update controls from within SubVIs.

There are no memory leaks that I can spot, I have been very careful with my closing of references.

The rigs have LV 8.6 run-time on them (one has 8.6 IDE), and I am developing on my laptop (and building the apps) with 8.6.1. I would not have thought this would cause this problem though?

[johnsold]

Look at the error and timed out outputs from the Preview Queue function.  I do not see how timeout could occur with a zero input, but it may be worth checking.  If an error ever occurs, it may point to a problem where the queue is being written.

Is there any way either of the subVIs could be blocked by something in another part of the program?

Lynn 

[Ben]

---

nrp wrote:

... GPIB power supply, non-NI encoder card.There is an event structure on the main UI.

One thing I am doing, is using a lot of control references to update controls from within SubVIs.

...

---

1) make sure you are using the latest a greatest version of the VISA driver. There was a bug in one version that would hang teh UI thread.

2) "Non-NI encoder card". If you are using dll calls to interface with that widget, check what color the node is. If I remeber correctly non-thread safe dll calls are orange be default indicating they run in the UI thread.

Just trying tp help,

Ben 

[Neil.Pate]

---

johnsold wrote:

Look at the error and timed out outputs from the Preview Queue function.  I do not see how timeout could occur with a zero input, but it may be worth checking.  If an error ever occurs, it may point to a problem where the queue is being written.

Is there any way either of the subVIs could be blocked by something in another part of the program?

Lynn 

---

The code in that screenshot should all happen quite quickly, the subVIs don't really do much other than encapsulate a really simple action engine (latched boolean to indicate an abort status). There really should not be anything in that loop that can cause a deadlock. I will try wiring the outputs to indicators though, just in case (it is a built application, so debugging is quite tricky).

[Neil.Pate]

---

---

1) make sure you are using the latest a greatest version of the VISA driver. There was a bug in one version that would hang teh UI thread.

2) "Non-NI encoder card". If you are using dll calls to interface with that widget, check what color the node is. If I remeber correctly non-thread safe dll calls are orange be default indicating they run in the UI thread.

Just trying tp help,

Ben 

---

Two great tips, thanks!

I will update the VISA driver asap.

You were right in the DLL calls were orange (something new I learned today, thanks again!).

I am using a (rather old) LV wrapper driver provided by the manufacturer. I see that in configuring the DLL call there is now a radio button to select whether to run the function in the UI thread or any other thread. Do you know if changing this (it was on UI thread and hence the orange node) may help or does this thread-safe behaviour need to be compiled into the DLL?

Message Edited by nrp on 08-25-2009 11:22 PM

[Ben]

Please read this post by Greg McKaskle. The decision to mark for UI thread should be determined by the developer of the dll itself to determine if it is thread safe.

I recall reading other posts by Greg that talked about wrapping the dll call in a non- re-entrant VI. This will prevent multiple calls into the same dll and let you "get away" with marking the call for a thread other than the UI.

I also believe I read Rolf making a wise-crack about all bets are off if you just try chanigng it to non-UI. It may work today but when it comes time to demo (Windows 98) it will blow-up.

Ben