Beware of the Get Variant Attribute function

[John Lokanis]

I have been unable to build a simple example of this bug so I have not reported it to NI yet, but I figured this was annoying enough to warn people about. Not sure if all the steps are needed to repro this, but I included them all anyways.

I have discovered in some complex code in my application that the 'Get Variant Attribute' function can sometimes behave abnormally. Here is what I am seeing:

I start with an empty variant (Top Variant).

I call 'Get Variant Attribute' to get a specific attribute (Parent Attribute 1) (if it does not exist, I should get an empty default variant).

I then add a sub attribute (Child Attribute 1) to the 'found' (or empty if not found) Parent attribute.

I then replace the Parent attribute in the Top Variant with this new variant (with the sub attribute attached). This is basically a tree structure.

So far, I have this:

-Top Variant

--Parent Attribute 1

----Child Attribute 1

I continue this until my Parent has several children:

-Top Variant

--Parent Attribute 1

----Child Attribute 1

----Child Attribute 2

----Child Attribute 3

----Child Attribute 4

----Child Attribute 5

I then remove these one by one by getting the Parent variant, calling 'Delete Variant Attribute' with a child as the attribute to remove and then replacing the Parent into the Top Variant. I leave child 3, however. Now I have this:

-Top Variant

--Parent Attribute 1

----Child Attribute 3

Now, I replace the Parent with an empty variant to 'Flush' the tree. Now I have this:

-Top Variant

--Parent Attribute 1

Here is where the bug comes in. Now I repeat the whole process, but for Parent Attribute 2. When I call Get Variant Attribute on the Top Variant and give it the name 'Parent Attribute 2', it should give me a default empty variant because that attribute does not exist in the Top Variant. Instead this is what I get:

-Top Variant

--Parent Attribute 1

--Parent Attribute 2

----Child Attribute 1

----Child Attribute 2

----Child Attribute 3

----Child Attribute 4

----Child Attribute 5

WTF? The new attribute seems to inherit all the child attributes that ever existed in the new Parent's sibling (which still exists, but is empty)

The fix is easy, however. Just wire an empty variant to the default value terminal of the 'Get Variant Attribute' function when you try to get an attribute and the problem goes away.

Just don't trust that the unwired default will really be an empty variant.

Now, as I said, I cannot seem to reproduce this with an example VI, but I can instrument my code and see this happening. I dump the whole Top Variant tree to a file before the call to 'Get Variant Attribute' and then right after. I also confirmed that the 'Found' output is false and the value output contains the 5 child attributes, even though nothing is wired to the 'default value' input.

[ned]

I think this is the same bug I found in 8.2. It already has a CAR assigned but I have no idea if it was fixed.

EDIT: Oops, should have checked before posting... it was reportedly fixed in 8.5. Might be a related problem, though.

Edited March 26, 2010 by ned

[John Lokanis]

Looks like they might have simply moved the bug instead of fixing it. As I said, I cannot reproduce it in a simple VI under the 8.6.1 dev environment, but I can reproduce it in my exe running under the 8.6.1 RTE. Not sure if the issue is in the RTE, or the fact that the code is inside a large massively parallel application where just about everything is a reentrant shared clone.

[Aristos Queue]

Ok... so based on your very light description of the bug, I asked another developer to inspect a particular table for a particular set of bits... and, lo, a bug was seen and will be fixed. Please confirm that the attached VI replicates your bug.

get_variant_attribute_unwired_default_test.vi

[John Lokanis]

Yes, I can confirm that appears to demonstrate the bug. My first CAR of 2010! And it applies to a LV version I have not even ported to yet!

Any idea when this CAR will be fixed and released? LV2010?

BTW: I thought the new version of LV was 2009, not 9.0!

[Adam Kemp]

BTW: I thought the new version of LV was 2009, not 9.0!

The version is 9.0. The name of the version is 2009. We have to store a version number in there somewhere, and our representation of version numbers can't handle 4 digits for the major version.

[hooovahh]

Yes, I can confirm that appears to demonstrate the bug. My first CAR of 2010! And it applies to a LV version I have not even ported to yet!

Any idea when this CAR will be fixed and released? LV2010?

BTW: I thought the new version of LV was 2009, not 9.0!

I've noticed the about says both 9.0 and 2009, and the Windows registry also has it as 9.0.