Bad bug that deletes data in a wire

[Wolfram]

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

[Grampa_of_Oliva_n_Eden]

QUOTE(Wolfram @ Aug 6 2007, 11:00 AM)

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

Thanks for sharing.

THe bug fix list for LV 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

[Tomi Maila]

I was able to reproduce the bug in LV 8.2.1 and LV 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 LV 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.

http://forums.lavag.org/index.php?act=attach&type=post&id=6547

main before execution

http://forums.lavag.org/index.php?act=attach&type=post&id=6548

main after execution

http://forums.lavag.org/index.php?act=attach&type=post&id=6549

subVI

http://forums.lavag.org/index.php?act=attach&type=post&id=6546

Tomi

[jzoller]

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.

QUOTE(Wolfram @ Aug 6 2007, 09:00 AM)

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

[Grampa_of_Oliva_n_Eden]

QUOTE(Tomi Maila @ Aug 6 2007, 12:38 PM)

I was able to reproduce the bug in LV 8.2.1 and LV 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 LV 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.

http://forums.lavag.org/index.php?act=attach&type=post&id=6547

main before execution

http://forums.lavag.org/index.php?act=attach&type=post&id=6548

main after execution

http://forums.lavag.org/index.php?act=attach&type=post&id=6549

subVI

http://forums.lavag.org/index.php?act=attach&type=post&id=6546

Tomi

I'll take care of reporting this to NI.

Ben

[Tomi Maila]

QUOTE(Ben @ Aug 6 2007, 07:46 PM)

I'll take care of reporting this to NI.

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

[Grampa_of_Oliva_n_Eden]

QUOTE(Tomi Maila @ Aug 6 2007, 12:49 PM)

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

[Tomi Maila]

QUOTE(Ben @ Aug 6 2007, 07:51 PM)

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.

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

[Grampa_of_Oliva_n_Eden]

QUOTE(Tomi Maila @ Aug 6 2007, 04:03 PM)

...the rookie....

:question: :clock:

No. Just the one that wants it fixed.

Ben

[Spex]

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

[Aristos Queue]

QUOTE(Tomi Maila @ Aug 6 2007, 03:03 PM)

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

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!

[jaegen]

QUOTE(Spex @ Aug 6 2007, 04:03 PM)

...

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.

...

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

[Tomi Maila]

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.

http://forums.lavag.org/index.php?act=attach&type=post&id=6559

Main VI passes data for subVI to be visualized

http://forums.lavag.org/index.php?act=attach&type=post&id=6560

SubVI uses value property node to modify the displayed data

http://forums.lavag.org/index.php?act=attach&type=post&id=6562

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

http://forums.lavag.org/index.php?act=attach&type=post&id=6561

Download the example project for LabVIEW 8.0

[Grampa_of_Oliva_n_Eden]

QUOTE(Tomi Maila @ Aug 8 2007, 05:11 AM)

I was thinking how bad this bug actually is. ...

This bug got me think as well.

How many times have you written (or read) that writing to a property node involves a buffer copy?

This bug demonstrates that rule of thumb as false.

I wonder if Dareen can develop a VI nalyzer test that will nial this contsruct?

I'll e-mail him.

Ben

[Dirk J.]

QUOTE(Tomi Maila @ Aug 8 2007, 11:11 AM)

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.

Some more observations, probably relevant for the dialog window use case.

You're not likely to experience this bug if you pass your data in clusters.

If the array is the only element of the cluster ... too bad, the bug is there.

If there's more than one element, and you're unbundling, then it works out.

[Darren]

QUOTE(Ben @ Aug 8 2007, 07:30 AM)

I wonder if Darren can develop a VI Analyzer test that will nail this contsruct?

I read through this thread a few times to get a better grasp on the problem. It seems to me that you would want a VI Analyzer test that detects whenever the Value property is written for a control that is wired on the connector pane. Does that sound right? I could write a test that would detect this case for implicit property nodes pretty easily, but for property nodes with control references wired to them, that's a different story. I could detect the Value property on a property node that is wired directly to a control reference, but once you start getting into cases where the control reference is passed through a loop border, a subVI, other property nodes, etc., it becomes much more difficult to develop.

So as it stands, I could pretty easily write a test that would detect implicit property nodes (or property nodes wired directly to control references) that are writing the Value property for controls on the connector pane. Would that be useful?

Please let me know if I missed the mark and the test should detect something different.

-D

[Grampa_of_Oliva_n_Eden]

QUOTE(Darren @ Aug 8 2007, 11:24 AM)

I read through this thread a few times to get a better grasp on the problem. It seems to me that you would want a VI Analyzer test that detects whenever the Value property is written for a control that is wired on the connector pane. Does that sound right? I could write a test that would detect this case for implicit property nodes pretty easily, but for property nodes with control references wired to them, that's a different story. I could detect the Value property on a property node that is wired directly to a control reference, but once you start getting into cases where the control reference is passed through a loop border, a subVI, other property nodes, etc., it becomes much more difficult to develop.

So as it stands, I could pretty easily write a test that would detect implicit property nodes (or property nodes wired directly to control references) that are writing the Value property for controls on the connector pane. Would that be useful?

Please let me know if I missed the mark and the test should detect something different.

-D

From what I have seen this just may do the trick! The question that remains is do those other code constructs manifest this issue.

Let us get back to you.

Ben

[Dirk J.]

another workaround, from a practical point of view.

use the 'reinitialize to default' method

[Tomi Maila]

QUOTE(Darren @ Aug 8 2007, 06:24 PM)

It seems to me that you would want a VI Analyzer test that detects whenever the Value property is written for a control that is wired on the connector pane.

Actually I'm not sure the bug is limited to these cases only. For now all the examples of the bug found have required a subVI border but I'm not sure if that is always the case with this particular bug. I think it would be better to let NI R&D to investigate what actually happens behind the scenes before writing a VI analyzer for the bug.

[Dirk J.]

QUOTE(Darren @ Aug 8 2007, 05:24 PM)

but for property nodes with control references wired to them, that's a different story. I could detect the Value property on a property node that is wired directly to a control reference, but once you start getting into cases where the control reference is passed through a loop border, a subVI, other property nodes, etc., it becomes much more difficult to develop.

Instead of using a property node 'directly'; wiring a reference (to the control) to the property node in Tomi's example for the graph control, the behaviour is the same.

[Darren]

QUOTE(Tomi Maila @ Aug 8 2007, 10:44 AM)

I think it would be better to let NI R&D to investigate what actually happens behind the scenes before writing a VI analyzer for the bug.

Well alrighty then...let me know if/when you guys want me to write a VI Analyzer test for this, and what specifically it should detect. Another idea I had was that the test could have a configuration option that would return a failure for *any* Value property on the diagram, as long as there is something wired on the conpane. That way you could sift through them yourself to make sure none of the non-implicit ones would cause the problem. Also, I noticed the Val(Sgnl) property also demonstrates the bug.

-D

[Yair]

QUOTE(Tomi Maila @ Aug 6 2007, 11:03 PM)

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

Yes, and since I already picked up all my champions stuff, I guess it means you're it.

P.S. Weren't you supposed to be here? You could probably have helped in the LVOOP early adopters session, which was almost the only session I was at which had proper content.

[crelf]

QUOTE(yen @ Aug 10 2007, 09:36 AM)

You could probably have helped in the LVOOP early adopters session, which was almost the only session I was at which had proper content.

This year's NI-Week had some excellent sessions and was the most technically-advanced one yet. We also got fewer technical sessions presented by marketing, and more by R&D. We also had more sessions presented by technical people in Alliance companies. No offense, but if you really think that only one or two sessions had "proper content", then you didn't go to the right sessions. Personally, I usually follow the "I don't bring engineers to NI-Week because there's not a lot of technical stuff" line - and this year's NI-Week has certainly changed my mind - expect to see more V I Engineering technical staff in '08...

PS: looks like we're trying to hijack the thread - if you'd like to discuss this further I suggest a new thread be created in the LAVA Lounge...

[Mike S.]

"this year's NI-Week has certainly changed my mind - expect to see more V I Engineering technical staff in '08..."

Hi crelf,

Your post caught my attention when you mentioned the company (that I assume you work for). Do you happen to know a guy named Stan Case? I used to work with him when he was with TASC. If you know him, tell him I said hi.

Regards,

Mike Summers

[crelf]

QUOTE

Your post caught my attention when you mentioned the company (that I assume you work for). Do you happen to know a guy named Stan Case? I used to work with him when he was with TASC. If you know him, tell him I said hi.

Sure do, but Stan left VIE several years ago (before I got here) - he's at Medtronic now.