I've encountered the following bug: See attachment
It is one of the bad and strange ones.

Wolfram

Edit:
I've replaced the attachment. There was a race condition in the
previous demonstration VIs.
Wolfram

This post has been edited by Wolfram: Aug 6 2007, 03:50 PM

Thanks for sharing.

THe bug fix list for LabVIEW 8.5 has an item that talks about writing to a control via property nodes and it over-rides a read from a local. I wonder if this is related.

This bug reminds me of trying to chip ECL circuits. Bad siganls can propogate backwards throught a gate there as well.

Ben

I was able to reproduce the bug in LabVIEW 8.2.1 and LabVIEW 8.5. I guess this issue is related to the LabVIEW in-placeness algorithm. Would you please report this bug to NI if you have not already done so.

What happens is that LabVIEW decides not to make a buffer copy for the subVI as it incorrectly thinks that the buffer is not modified by the subVI. However the buffer is modified by the subVI by calling a property node for an indicator. As a buffer copy is not made, the call to the property node actually modifies the original buffer. This results the buffer to become empty after the subVI call. I changed the property node for local variable and the bug disappeared. Replacing the local variable with property node reproduced the bug once again. The bug appeared for both value and value (signalling) properties.

I found even stranger issue. The buffer modifications "backpropagate" to a constant on block diagram. See the attached project (for LabVIEW 8.5). To reproduce, open block diagram of main.vi. Take a look at the constant there. Then run the VI. Hide the block diagram and show it again by pressin Ctrl+E twice. The constant value has been modified.


main before execution




main after execution



subVI


 buffer_backpropagation.zip ( 16.35K ) Number of downloads: 93


Tomi

Nice find, and a very good demonstration. I can confirm this bug for 6.0.2, 7.0, 7.1, 8.0 and 8.2.1,

Some observations:
-Replacing the sub-vi graph with a simple data indicator: still bugged.
-Replacing the sequence loop with a case statement: still bugged.
-Replacing the clusters/arrays with dbls: still bugged.
-Replacing the top level sequence loop with other error primitives (flatten/unflatten) and wiring the errors: still bugged.
-Replacing the sub-vi value property node with a local: bug goes away.
-Routing the error wire in the top level vi around the sequence: bug goes away.
-The bug doesn't appear on the first run, but does appear on subsequent runs. Ouch...

Looks like a ref to the sub-vi data is being incorrectly retained where the data enters the top level sequence loop.

Very nice find!

Joe Z.

I'll take care of reporting this to NI.

Ben

I was just about to file a report bu you do that After all you are a champion and have more direct channels...

OK, I'll do it this time but if you ever make Champion (hack, cough cough...), I'll expect you to do all of the bug reports.

Service Request = 1007895.

Matt will update this thread with CAR once filled.

Ben

Is it always the rookie that files all the bug reports?

No. Just the one that wants it fixed.

Ben

This was reported to R&D (CAR #4C5FFLRK). Thanks for taking the time to report and investigate this everyone.

Another workaround (aside from Joe's method of using a local variable) is to force LabVIEW to copy the data in the wire before it is passed to the sub-VI or the sequence structure in the top-level VI. The bigger trick is predicting when this is going to happen . Good catch, and thanks for the simple example.

Spex
AE

This is like Supreme Court Justice Stephen Bryer... in an interview, he said he had been the newest justice for 12 years, and the newest justice is the one who has to answer the door if anyone knocks while the judges are debating. 12 years of answering the door!

This is the exact sort of thing I imagined that new "Always Copy" primitive would be used for when I first saw it ... it's a perfect workaround for memory manager bugs (not that there are ever any of those ).

Jaegen

I was thinking how bad this bug actually is. I found a very common use case of passing data to dialog windows where this bug can cause a lot of harm.

When a main VI calls a subVI that is used to display data it's common to use value property nodes within the subVI. However using value property node may cause severe troubles as this bug modifies data in constants and wire buffers elsewhere in the calling VI. See the images below for this use case.


Main VI passes data for subVI to be visualized



SubVI uses value property node to modify the displayed data



Main VI after execution, moving mouse over the constant displays the changed constant value


 buffer_bug_8.0.zip ( 15.04K ) Number of downloads: 77

Download the example project for LabVIEW 8.0