Error ring excluded in executable?

[bokorpet]

Hello,

I encountered following strange behavior: when run in LabVIEW development, following error ring does its expected job as it also acts as a control flow control so that the reference is not destroyed before the loop terminates (see picture).

Strangely, when I build an executable and execute the VI via run-time, I the reference is destroyed WHILE the loop is still running. As if the error ring was not compiled into the executable.

Is it a LV bug?

Thanks,

Peter

[tst]

While it might be possible that this is the case (the ring is an XNode and I suppose it is theoretically possible that there are some holes in that department), I would say it doesn't seem to be likely for something as basic as this. I would suggest making sure (e.g. by adding logging to see whether the loop is still running, whether the code to destroy the DVR was actually called, etc.). You could also try replacing the ring with a constant or a clear errors VI.

Other alternative explanations would be that you destroy the DVR elsewhere, that the DVR isn't destroyed and you're misinterpreting the behavior or that the DVR is destroyed automatically because the hierarchy it was created in has gone idle.

[crossrulz]

I see you are already passing out another error cluster from the loop.  Why not use that error cluster?  The Destroy DVR function will still work if there is an error (or so the help file for it claims).

[bokorpet]

I managed to reproduce the problem in LabVIEW development if I disable debugging for this VI.

It seems to me that the compiler moves this part of the code outside the loop as static content. In this case, I would consider it as a bug, as the compiler shouldn't change the semantic of the program.

What do you think?

[crossrulz]

---

@Bokor wrote:

I managed to reproduce the problem in LabVIEW development if I disable debugging for this VI.

It seems to me that the compiler moves this part of the code outside the loop as static content. In this case, I would consider it as a bug, as the compiler shouldn't change the semantic of the program.

What do you think?

---

I don't see this as a bug.  There are some in LabVIEW R&D that say that using the error wire to force a data dependency is a hack.

I still go back to the fact that you should just be using your other error wire or wire your DVRs through your loop.

[tst]

---

@crossrulz wrote:

I don't see this as a bug.

---

I would. Hack or not, the paradigm we rely on is that wires determine execution order and I'm not aware of any change that NI made to that rule (notable kind-of-exceptions - inputs into later frames of a flat sequence not affecting the earlier frames and iteration order in a parallel loop, but tha's not really wires).

That said, we would need to see some actual code demonstrating the behavior.

[bokorpet]

Here you go (LabVIEW version 2014).

Just by enabling/disabling debugging for main.vi can you switch between "I'm alive" (valid DVR) and "Dereference error" (destroyed DVR).

There may be different views whether or not it's a bug (I tend to agree that it is), but at least it should be documented..

[tst]

I agree that it looks like a bug and I'll report it.

Also, here's a simpler version of the behavior (2013).

[Darin.K]

I agree that this is a bug with a capital 'BUG'. 

It is a compiler optimization run amok.  

Any node which ignores input errors (Release Queue, Close Reference, etc.) will do the trick.

The error ring is also fungible.  Create a Diagram Disable structure with an error output (use a constant if you want) wired in the disable case.  In the enabled case simply use the tunnel with the 'Use Default if Unwired' option.

Snippet mangled the simpled 'This VI constant, but this also shows the bug.

[JÞB]

And the error ring has nothing to do with it really.  But lets look at what we did that is a bit odd

Dropping back to the concept here

Shows how to correctly use the DVR functions thusly:

Go read it yourself and compare to the simplified example attached above.

Finally Modifying the example to:

CURES the unexpected behavior!

DVR Write DVR output unwired should probably have thrown at least a compiler warning.

I'm fairly certain that one should not wire a DVR Ref Around a parallel DVR Access that may modify the data (Something scares me there).

So Bug? Yes, I think the behavior is not as intended.  Workaroud? Don't wire a DVR Ref around a parallel DVR Access that may modify the data