Generic LVClass probes have problems when using classes as data members

[Aristos Queue]

Affects both 8.2 and 8.2.1.

There is an issue with generic probes of LVClasses. The problem arises only when a parent class uses another class as a data member and you probe a wire of a child class.

Assume 3 classes: Parent, Child and Other. Child inherits from Parent.

Parent's private data cluster contains an instance of Other.

Other's private data cluster contains a numeric.

Child's private data contains a numeric.

Set the value of Child's numeric to be 10, then probe a Child wire. The 10 will show up in Other's cluster. In this case you simply get misleading information in the probe, which is bad enough. But if Other uses a string instead of a numeric in its private data control, the 10 will be written where the address of the string is supposed to be in memory, leading to a crash (since 10 is not a valid memory address).

This issue is known and will be fixed in the next version of LabVIEW.

Addendum: I do really want to know how so many of us managed to use classes for 11 months after release before this got found. It hasn't even been reported from customers... my teammate found it randomly while working on something else. It amazes me sometimes just how long a seemingly common bug can go undetected.

[Yair]

Well, I think this is a first. A LabVIEW R&D member preempting the users and reporting a bug. Congratulations, Stephen!

[crelf]

Don't forget to post the CAR#

[Tomi Maila]

QUOTE(Aristos Queue @ Jul 10 2007, 10:12 PM)

Addendum: I do really want to know how so many of us managed to use classes for 11 months after release before this got found. It hasn't even been reported from customers... my teammate found it randomly while working on something else. It amazes me sometimes just how long a seemingly common bug can go undetected.

One reason might be that when LabVIEW crashes often without obvious reason without any obvious reason and you have reported dozens of bugs within the last year, you just get tired of troubleshooting every crash and go on...

[gb119]

QUOTE(Aristos Queue @ Jul 10 2007, 08:12 PM)

Addendum: I do really want to know how so many of us managed to use classes for 11 months after release before this got found. It hasn't even been reported from customers... my teammate found it randomly while working on something else. It amazes me sometimes just how long a seemingly common bug can go undetected.

Ahhh, so it wasn't just me then. Actually it hadn't been a big enough problem for me to spend the time trying to work out why one of my classes always crashed when probed - I'd sort of assumed it was something to do with the class data structure, but I hadn't got as faw as working out some test cases. Good to know it'll be fixed...

[Aristos Queue]

QUOTE(Gavin Burnell @ Jul 10 2007, 03:25 PM)

Ahhh, so it wasn't just me then. Actually it hadn't been a big enough problem for me to spend the time trying to work out why one of my classes always crashed when probed - I'd sort of assumed it was something to do with the class data structure, but I hadn't got as faw as working out some test cases. Good to know it'll be fixed...

In my best Mrs. Cake voice (from Terry Pratchett novels):

Ah, lad, ye gots to report ye crash or how canaye fix yon bug?!

[jaegen]

QUOTE(Aristos Queue @ Jul 10 2007, 03:18 PM)

In my best Mrs. Cake voice (from Terry Pratchett novels):

Ah, lad, ye gots to report ye crash or how canaye fix yon bug?!

Perhaps NI needs to provide a bug reproducibility toolkit

Honestly, that's the only thing that ever stops me from reporting a bug. When you're working on a project with 2000 VIs, and the bug appears to involve dynamically registered events, timed while loops, call-by-reference, sub-panels, UI thread issues, strange MS Windows interactions, and the phase of the moon, trying to create a pared-down VI that reproduces the bug is usually much more work than finding a workaround - especially if it only appears in a built executable.

Thanks for the voluntary bug report though - I'm much, much more pleased with the disclosure than I am disappointed about the existence of a bug.

Jaegen

[TG]

QUOTE(Aristos Queue @ Jul 10 2007, 07:12 PM)

Addendum: I do really want to know how so many of us managed to use classes for 11 months after release before this got found. It hasn't even been reported from customers... my teammate found it randomly while working on something else. It amazes me sometimes just how long a seemingly common bug can go undetected.

Id be interested in who is using LV classes and for what purpose.

My exp with LVOOP so far has been guarded.

[Aristos Queue]

QUOTE(John Rouse @ Jul 11 2007, 12:42 PM)

Id be interested in who is using LV classes and for what purpose.

My exp with LVOOP so far has been guarded.

I'll be free to talk about NI's use of it at NI Week, but not until then. All I can say is it is pretty extensive for such a new feature. Of the new features I've seen added to LV over the years, the event structure is the only one I can think of with a bigger impact on programming style of our G programmers. NI's overall adoption has been somewhat limited by the lack of support for classes under RT and the embedded targets, something I hope to remedy in the coming years.

[Yair]

QUOTE(Aristos Queue @ Jul 11 2007, 01:18 AM)

In my best Mrs. Cake voice (from Terry Pratchett novels):

Ah, lad, ye gots to report ye crash or how canaye fix yon bug?!

We could answer with "We aten't feeling like it" or "WE DON'T WANT TO".