I ran into a consistent crash of my code running interactively on a cRIO.
The attached VI is a slimmed down version of the code that crashed it.
The code crashed in the auto-index on the for loop border. With help of my colleague wiebe@CARYA I've traced it to a possible bug when using an object as map type and then using the for loop to get all map items. In my original code the object was a parent type with several possible childs.
The code above crashed it initially but after several tries with other types in between it stopped crashing, so it's not consistent.
A simple type like an integer didn't crash it though.
The always-copy didn't help in any way, it can be discarded.
LV 19.0.1f1 32-bit, RT 19.0.0
cRIO 9056: FW 7.1.0f0 ,RIO 19.5 sept 2019
Solved! Go to Solution.
I'm sorry your code is crashing (sometimes) but I have a very similar case.
I have a map of Actor Framework Message Enqueuers (string as key) and am also autoindexing into a For loop.
My cRIO crashes in this case, fairly quickly but not immediately.
I had considered some sort of memory leak, but I
a) haven't found the leak, despite quite extensive use of the RT Execution Trace Toolkit, and various memory profiling tools (together with CPU, which is comfortably sitting around maybe 20%)
b) don't appear to have growing memory usage (as reported by e.g. grep on /proc/<process id> or the System Config VIs)
More details can be found in my forum post here: Deallocate Memory on cRIO with Network Streams and AF
Wiebe also gave me help with that...
I'm going to post there now and update my record/findings.
Edit: Any chance it works if you have an empty Map, but not when you have a map that had elements added then removed (and so it became empty?)
Thanks Cristian for confirming somewhat.
My solution was to replace the map from which I needed all keys with a variant "database" (attributes) and it works like a charm.
I can reliably (not sure that's appropriate here, but anyway) crash my cRIO with the following code, running "interactively", or however it is called:
Code runs happily until I click Insert, at which point I lose connection to the cRIO.
Do it again, and I get the blinking yellow lights.
Remove on an empty set (whilst not changing anything) doesn't appear to cause problems, so I'm pretty sure that the For loop is the problem...
Note that this code works fine with a Set (and no Iteration input to the Insert, just the string type).
I've tried replicating this with 19.5 and I'm not seeing any crashes on RT. It sounds like you have a larger VI that is more consistent. Could you provide it? This may have also been fixed between 19.0 and 19.5. Could you try it on 19.5?
Product Support Engineer
There's actually a bug fixed in 2019 f2 that may be related to what you're seeing: http://www.ni.com/product-documentation/55191/en/
I can't guarantee upgrading will fix anything for you, but I think it's worth a shot.
I can't speak for Andre, but I had a similar conversation with a Service Engineer yesterday and after upgrading to LV Real-Time 19.5.1 and LabVIEW 2019 SP1 (and updating the versions on the cRIO), I didn't observe any improvements.
The hypothesis I was given was that the cRIO I used was Intel based, but it couldn't be reproduced by the engineer on an ARM cRIO. Is it possible you're also trying with an ARM device?
The f2 you are referring to seems to be for 19.0.0, I'm running SP1 f1.
As for the code, it's being developed under an NDA, so I would either have to remove all classified stuff from an older revision.
The small code sample did produce the abnormal RT runtime termination on multiple runs.