LabVIEW crash unless recompile...

[PaulL]

Can anyone suggestion suggest a cause, workaround, or method to diagnose the following problem?

1) If I open LabVIEW and then my top-level VI and run the application, LabVIEW always crashes (a Windows error screen appears!) at an instance of a call to "DataSocket Open."

2) If, however, after I open my top-level VI, force a recompile of the VIs in the hierarchy, and then run the application, everything works fine. (Note that if I then save all the files and then go back to method 1 LabVIEW still crashes.)

A couple notes:

The inputs to the DataSocket Open are the mode (Write), an error cluster, and, more importantly, a shared variable that comes from the private data of a LVOOP class. (A class method 'initialize' writes the shared variable to the class.)

Broadly, the application flow to the point of the crash is initialize...deploy shared variable libraries...subscribe to shared variable events...open DataSocket connections to shared variables--and that is where the crash occurs (if I don't force a recompile).

OK, I just created and attached a very simple example that exhibits the same crash behavior. (I didn't programmatically deploy the variable library in this example, but that isn't relevant.)

[Tomi Maila]

QUOTE(Paul_at_Lowell @ Jul 28 2007, 03:32 AM)

OK, I just created and attached a very simple example that exhibits the same crash behavior. (I didn't programmatically deploy the variable library in this example, but that isn't relevant.)

Eh, there is not a main level VI in the example. Pehaps you should have an example that is runnable as well i.e. there is a main level VI.

Tomi

[Aristos Queue]

QUOTE(Tomi Maila @ Jul 28 2007, 09:31 AM)

Eh, there is not a main level VI in the example. Pehaps you should have an example that is runnable as well i.e. there is a main level VI.

I believe that you are meant to open and run

ExecutionControl.lvclass:controlMainFlow.vi

That is the main VI.

[PaulL]

QUOTE(Aristos Queue @ Jul 28 2007, 04:06 PM)

I believe that you are meant to open and run

ExecutionControl.lvclass:controlMainFlow.vi

That is the main VI.

Yes, that's the one! Sorry I didn't make that clear.

I tried converting the shared variable name to text first (see attached) but this solution exhibits the same behavior. (A while back I encountered troubles using shared variable nodes inside classes, which is why I am using the DataSocket protocol anyway.)

[Tomi Maila]

This is some internal LabVIEW bug. Only the NI engineers have tools to debug LabVIEW internal code and locate the bug. You should contatc your local NI support for futher investigation. The ExecutionControl class is irrelevant for the crash, you should replace it with a single main VI to make it simpler for NI engineers to locate the bug. Provide step-by-step instructions how to reproduce the crash, which LabVIEW version you are using and which operating system are you using. NI engineers try to find you a warkaround if that's possible, at least if you have a support contract. Even without a support contract you should submit the issue to local NI support as it's a LabVIEW bug.

Tomi

[PaulL]

For the record, NI support found the following:

1) The problem only occurs if the method that calls the DataSocket function is wired with dynamic terminals. Rewiring these terminals as nondynamic (if possible) gets around the problem.

If 1) is not possible (e.g., dynamic terminals are necessary) then

2) use a wrapper VI around the DataSocket library VI. (This is a variation on 1 since the wrapper won't need dynamic terminals.)

I implemented such wrappers with the same connector panes as far as possible as the DataSocket library VIs (I had to use variants as necessary, with a type conversion on the output of the read wrapper) and so far this has worked for me....

[Aristos Queue]

QUOTE(Paul_at_Lowell @ Aug 21 2007, 02:54 PM)

1) The problem only occurs if the method that calls the DataSocket function is wired with dynamic terminals. Rewiring these terminals as nondynamic (if possible) gets around the problem.

The problem also occurs if you call Datasocket Open using a Call By Reference node. The problem is not restricted to LV classes. It is restricted to any dynamic invocation of the VI containing Open Datasocket primitive. The wrapper workaround works for this case as well.