Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Debug RT Application Crashing

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.  

 

0 Kudos
Message 11 of 17
(424 Views)

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.


Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
Interesting in learning all you can about automotive CAN bus communication? Checkout my 12 part CAN Blog series.
Checkout and help contribute to the community driven LabVIEW Wiki.

0 Kudos
Message 12 of 17
(416 Views)

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. 

0 Kudos
Message 13 of 17
(407 Views)
Highlighted

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. 

0 Kudos
Message 14 of 17
(379 Views)

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?


Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
Interesting in learning all you can about automotive CAN bus communication? Checkout my 12 part CAN Blog series.
Checkout and help contribute to the community driven LabVIEW Wiki.

0 Kudos
Message 15 of 17
(372 Views)

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. 

0 Kudos
Message 16 of 17
(366 Views)

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.


Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
Interesting in learning all you can about automotive CAN bus communication? Checkout my 12 part CAN Blog series.
Checkout and help contribute to the community driven LabVIEW Wiki.

Message 17 of 17
(263 Views)