Coerce Cluster (with single variant element) to Variant Bug [974336]

[Jim Kring]

[Update: NI Bug 974336]

There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).

Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.

Coerce to Variant Fail (LV2019).vi

 

Note that adding another element to the outer cluster causes the problem to go away.

Edited February 15, 2020 by Jim Kring

[Jim Kring]

Filed with NI R&D: Bug 974336

[Aristos Queue]

Found a fix for this. It should be fixed in LV 2020.

The bug ONLY affects copying from a 1-element cluster of variant to a variant. Or a cluster of cluster of variant to a variant. Or... you get the idea... "any number of cluster-shells all containing 1 element, culminating in a variant" being copied to a variant.

This was a fun bug... consider this:

The memory layout for an byte-size integer is

{ 8 bits }

The memory layout for a cluster of 1 byte-size integer is

{ 8 bits }

They are identical. "Cluster" doesn't add any bits to the data. That's just the type descriptor for the data in that location.

This is true for any 1-element cluster: the memory layout of the cluster is the same as the memory layout for the element by itself. This is true even if the 1 element is a complex type such as a nested cluster of many elements or an array.

When a VI is compiling, if data needs to copy (say, when a wire forks), LabVIEW generates a copy procedure in assembly code. For trivial types such as integers, the copy is just a MOV instruction in assembly code. But for compound types, we may need to generate a whole block of code. At some point, the complexity is such that we would rather generate the copy procedure once and have the wire fork call that procedure. We want to generate as few of those as we have to -- keeps the code segment small, which minimizes page faults, among other advantages.

We also generate copy procedures for compound coercions (like copying a cluster of 5 doubles into a cluster of 5 integers).

Given all that, LabVIEW has some code that says, "I assume that type propagation has done its job and is only asking me to generate valid copy procs. So if I am asked to copy X to Y, I will remove all the 1-element shells from X and all the 1-element shells from Y, and then I will check to see if I have an existing copy proc."

Nowhere in LabVIEW will we ever allow you to wire a 1-element cluster of an int32 directly to an int32. So the generator code never gets that case.

In fact, the only time that we allow a 1-element cluster of X to coerce directly to X is... variant. The bug was that we were asking for a copy proc for this coercion, and the code was saying, "Oh, I have one of those already... just re-use copy-variant-to-variant." That will never crash, but it is also definitely not the right result!

We had to add a check to handle variant special because variant can eat all the other types. So if the destination is variant, we have to be more precise about the copy proc re-use.

I thought this was a neat corner case.