Debug RT Application Crashing

[vipillai]

Okay this is odd. I had this reproducing on a colleague's cRIO last week. I switched cRIO's and made sure I have versions 17 of everything installed (same as before). I was going to update my Open Device Protected, to make sure the RT application no longer crashes, but now when I run the RT main I get the attached error and thus can no longer reproduce the crash on this new cRIO 9066. Have you seen this error before? I haven't made any changes besides moving the dependencies and the RT main to the new cRIO. 

Also attached is a screenshot of my project explorer.  

[Hooovahh]

That error is an expected one if the RT doesn't crash.  The crash will show that it is disconnected from the target, a non crash will result in that error coming through because the helper loop (the one with the dequeue) quit before being issued a quit command.  I was just ripping out the code from smaller test projects trying to minimize it for posting purposes and so I forced that helper loop to just quit on its own resulting in the error you see.

Well I do hope you can reproduce the issue.  As I stated my target is a cDAQ-9132 and I attached the reports from MAX so you can see the configuration it has.

[vipillai]

Awesome, I got it reproducing again and can verify that adding an obtain queue removes the crash. I will discuss this crash with some colleagues before submitting a CAR, and will post here with the CAR number when I have it. 

[vipillai]

Hi Hooovahh,

There definitely seems to be odd behavior with the way invalid or absent references are being dequeued causing an RT crash. This definitely could be a bug since after speaking to colleagues it does not seem like this should be expected behavior, so I think the best option here is to file a bug report service request at ni.com/support. You can link this forum post in the problem description. 

[Hooovahh]

I don't mind going through and opening a service request, but the issue is reproducible, and you agree that an unexpected crash is not the correct behavior so why can't a CAR be generated here?

[vipillai]

A service request can be more easily tracked by R&D and our AE department internally than a forum post. Also, just to be completely transparent, I am not familiar with LabVIEW OOP at all (did not even realize the project had OOP stuff until a colleague pointed it out end of last week), and thus a ticket opened with someone from our RT team that is more familiar with OOP would be better suited to address this potential bug and document the CAR. I'm sorry for the inconvenience, but I just want to make sure R&D has a contact from our support department that fully supports all the components of this crash. 

[Hooovahh]

Quick update.  After some discussion a CAR was assigned to this, CAR #668124, which claims to have been fixed in XNet 17.5.  I haven't updated and tested it yet but intend to.

[Hooovahh]

So I'm seeing this same problem again starting to pop up now that I'm trying to use CAN FD on my hardware, and I'm wondering if this fix didn't get applied to all parts of the XNet API.

I've been on 2018 SP1 F4, and XNet 18.5 for a while and things have been more or less stable and working fine.  But recently I had a request to support CAN FD and started ripping up code to add that support.  After getting it working and talking fine I was happy and started testing it out.  I found that as long as I was only talking to one CAN port it works fine, but if I had one port using CAN FD, and another using standard high speed CAN, then I would find that at times references like queues, and DVRs would go bad at random times and things would lock up waiting for a response from a queue, or just hard crash the RT controller just like before.

I took the plunge and updated to 2019, and XNet 19.1, reinstalled all my libraries, formatted and updated my controller, and ran some demo code that opens both ports to different databases and reads the signals.  Oddly enough I found that as long as there was nothing to actually read on the CAN buses things worked fine.  But as soon as I turned on my DUT and it started transmitting on both buses the controller would crash.  Attached is the crash reports, and MAX report.  I have some minimized code that reproduces it but it isn't in a state that can be shared yet.  Help me NI you're my only hope!

[Hooovahh]

Okay continuing with throwing things over the digital fence.  I recently received some USB-8502s and figured I'd give that hardware a try and see what happens in Windows.  Turns out LabVIEW crashes with an access violation.  Attached is the report which I did send to NI.  Do I need to open a CAR for this?