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.

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

Don't forget to post the CAR#

Thanks a lot for reporting this! It's very nice to see this kind of publicity politics from NI. I'd really appreciate if NI would publish the list of at least all the most severe LabVIEW bugs they are aware of...


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...

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?!

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

Id be interested in who is using LabVIEW 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 LabVIEW 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.

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