LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Cluster addition bug

I find tst's two samples, as modified the cluster to control and not use global variable, or property node value item, but connect it directly, the result is correct at LV7.0.

Yup, we use global variable or property node value item of cluster usually, that will trap us.

________________________________________________________


Try to make everything Automatic
Message 21 of 23
(959 Views)


@Yukee wrote:

I find tst's two samples, as modified the cluster to control and not use global variable, or property node value item, but connect it directly, the result is correct at LV7.0.


The original was not a local but a typedef cluster which came out of an LV2 global, so replacing with a control is not an option. The local is there because that's the simplest way to demonstrate the problem - it doesn't require any additional VIs. The solution, as already mentioned, is to only unbundle the value once.


Altenbach Wrote:


@Ben wrote:

PS I do not have time to invesatigate but this sounds like the "data flowing backwards" bug.

I think it is more complex than just "flowing backwards". It is really strange, e.g. if you do execution highlighting, all unbundle outputs show as zero and the wrong values only appear after the increments. Even a probe placed right before the increment still shows zero. ...


I would also agree that my initial description of the data going back to the unbundle node was inaccurate. This appears to be a buffer reuse issue, which would explain what you need a local to trigger it, although I have no idea which buffer is the being reused. What really surprised me was how it screwed up the array as well. I tried typecasting the various wires to see if there was any additional data, but couldn't find any.

This actually reminds me most of Stephen Mercer's story about the multiply node bug. They said that story was fictional, but now you can see that it is grounded in some reality. Smiley Very Happy


___________________
Try to take over the world!
Message 22 of 23
(947 Views)
Hi,



The name "Build Array Bug.vi" seems a bit misplaced...


If you replace the build array with a "Compound Arithmatic" Add, you also get wrong results.


And even the Format Into String doesn't work like it should.


Well, it looks like LV makes only one buffer for the named item. "Show Buffer Allocations" seems to confirm that.


Regards,


Wiebe,


"tst" <x@no.email> wrote in message news:1149019808163-372162@exchange.ni.com...
OK, I decided to do one version of Jason's idea and see if I could use this bug to build an obfuscated Hello World program (ignore the fact that the numbers are wrong, I was going to change them using trial and error). Unfortunately, this time it seems that the data in the wires is so messed up that all the elements in the array are 146 even though only the last element wired into&nbsp;the Build Array primitive is 146 (it looks like LV agrees with my method Smiley Wink ). Can anyone please confirm that this is not happening in 8.



Build Array Bug.vi:
http://forums.ni.com/attachments/ni/170/187463/1/Build Array Bug.vi
0 Kudos
Message 23 of 23
(941 Views)