Found a way to corrupt libraries programmatically within LabVIEW, where to report?

[MarkCG]

I discovered, by accident, a way to render a library or class corrupt, by doing a certain operation on it from within LabVIEW. Breaking the lvlib also breaks its member VIs, until they are unlinked.  No, it does not involve munging the XML or raw text of the lvlib. I have demo VI but am a bit loathe to just put it out there for the world. What should I do? What's a good place to report it?

 

 

[Antoine Chalons]

Call NI to obtain a SRQ from NI so that is issue is followed and can give birth to a CAR.
Or go to ni.com/ask and connect with you NI profile, it's pretty similar to calling, you only "lose" 1 or 2 days depending on how busy the AEs are, the advantage of that is that you can follow all the SRQs linked to your NI profile by logging on on ni.com/ask, I find it quick and easy.

[Mr Mike]

Call NI to obtain a SRQ from NI so that is issue is followed and can give birth to a CAR.

Or go to ni.com/ask and connect with you NI profile, it's pretty similar to calling, you only "lose" 1 or 2 days depending on how busy the AEs are, the advantage of that is that you can follow all the SRQs linked to your NI profile by logging on on ni.com/ask, I find it quick and easy.

 

And don't forget to post the CAR number in this thread!  

[Darin]

Personally I see no issue posting the code here, I have posted plenty of "This will crash LV" examples with sufficient warnings.  How about a screenshot at least of the offending code.

 

I have seen a few of these bugs in the scripting world, especially with the private methods, don't know if that is what you were doing or not.  I have taken to dumpster diving into the lvlib, xctl, and lvclass files directly since I find the scripting methods are slow (insist on loading everything when all I want is an icon or something), buggy, or do not exist. 

[Aristos Queue]

Personally I see no issue posting the code here, I have posted plenty of "This will crash LV" examples with sufficient warnings.  How about a screenshot at least of the offending code.

Code may well include proprietary information from the project he is working on. This is frequently the case with bug reports that NI receives.

[MarkCG]

Thank you for the advice! I didn't want to call, and go through the process of explaining the whole thing/ waiting on phone. I'll definitely use the online service request, thank you for that pointer Antoine. I will post CAR # when I get it Mr Mike. And to Darin and AQ, it's not so much a proprietary thing as that I was advised that I should try to disclose in a responsible way given nature of bug.  

[GregFreeman]

You're in Austin, just walk over to building C and drop it in someone's mailbox .

 

But seriously, when I have stuff like this I go the online route so that I can work on other things until they get back to me. Although the AE support is decent, it's usually a case of try these 10 things (which you already have), let me check for any internal knowledgebases, then it gets escalated. I'd prefer to let them just crank on it and shove it through the necessary channels without a phone conversation. 

[JeffP]

I filed CARs 408389 and 408391 for this issue.