Not a Refnum? Bug

[Porter]

I think that I've encountered a bug in the behavior of Not a Number/Path/Refnum? when checking an array of event references within a loop. *LabVIEW 19.0.1f3, 32-bit, Win10*

I would expect Loop1 (below) to stop within 6-7ms, however it is consistently timing out (>500ms). The result of the Not a Number/Path/Refnum? is always false even though the event refs are no longer valid.

I suspect that this is related to compiler optimization because adding an in-place structure results in the correct behavior.

So is this actually a bug? or should the need for an in-place structure be expected for some reason?

Here is my test VI (LabVIEW 2019) to demonstrate this behavior: Destroyed Event Ref Test.vi

 

[Darin]

In the world of C it is up to us to declare variables such as those Refnums as 'volatile' so the compiler knows they may change despite the appearance of being loop invariants.  I would say it is a bug that the LV compiler does not treat Refnums as volatile.

I'd say most of your workarounds would work, but are in (slight) danger of being optimized away as the compiler improves.  Personally, I'd drop an 'Always Copy' node instead of the IPES.

[Porter]

14 hours ago, Darin said:

In the world of C it is up to us to declare variables such as those Refnums as 'volatile' so the compiler knows they may change despite the appearance of being loop invariants.  I would say it is a bug that the LV compiler does not treat Refnums as volatile.

I'd say most of your workarounds would work, but are in (slight) danger of being optimized away as the compiler improves.  Personally, I'd drop an 'Always Copy' node instead of the IPES.

Thanks Darin for hitting the nail on the head. Always Copy was the first thing that came to mind when looking for a workaround, but muscle memory brought me to IPES first (which does the same thing if I recall correctly). For completeness, I have added Always Copy to Loop5 of my test vi. It solves the problem nicely:

Destroyed Event Ref Test_loop5.vi