Showing results for 
Search instead for 
Did you mean: 

LV Real time crash on specific map use with objects

Go to solution

Hi all,


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.

RT bug reproduction.png

The code crashed in the auto-index on the for loop border. With help of my colleague 




André (CLA, CLED)
0 Kudos
Message 1 of 17


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

0 Kudos
Message 2 of 17

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.

André (CLA, CLED)
0 Kudos
Message 3 of 17

I know what I'm doing tomorrow...

I'll let you know (and then I'll let NI know 😉 ) if that fixes my issue too.

0 Kudos
Message 4 of 17

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

Message 5 of 17

As you stated/predicted, the following is fine:



Guess I'll move to variant attributes for a while.

0 Kudos
Message 6 of 17

Hi André,


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?


Best regards,

Brian P.

Product Support Engineer

0 Kudos
Message 7 of 17

There's actually a bug fixed in 2019 f2 that may be related to what you're seeing:


I can't guarantee upgrading will fix anything for you, but I think it's worth a shot.

0 Kudos
Message 8 of 17

Hi Brian,


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?

0 Kudos
Message 9 of 17

Hi Brad,


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.

André (CLA, CLED)
0 Kudos
Message 10 of 17