Event structure bug?

[bjustice]

lockup.vi

I ran into a strange LabVIEW (bug?) today.  (Note, I'm using LabVIEW 2020 SP1)  Figured it was worth sharing, maybe you guys have insight here.  I've attached a VI that demonstrates the behavior.

Basically, if you click the "Do" button, then LabVIEW will completely lockup.  You have to hit the abort button or task kill to escape the lockup.

In the "False" case below, the event structure loop doesn't get kicked off.  However, it seems like LabVIEW locks up when the Do button is pressed... perhaps indicating that LabVIEW is waiting for the event structure to fire off the event... which, of course, never happens in the False case.

What's even stranger is that if you flip the disabled structure, you'll see that the code doesn't lockup if the case structure is given a constant False input.  This tells me that compiler shenanigans are at play.

Weird weird weird

[ShaunR]

I'd say it's a bug. If you uncheck the "Lock FP" for the "Do" case it works as expected. Clearly the FP locking is being triggered when it shouldn't. Changing the compiler optimisation has no effect so maybe it's something else. Rather nasty IMO. Congrats for isolating it.

Also does it in 2009 so I suspect it's been around for a while.

[LogMAN]

This is expected behavior: Ensure That Event Structures Handle Events whenever Events Occur - LabVIEW 2018 Help - National Instruments (ni.com)

Quote

LabVIEW begins queuing events when the VI runs or is reserved to run. The Event structure handles a queued event when data flow allows the structure to execute. Therefore, LabVIEW can generate events before an Event structure is waiting to handle them.

Quote

Caution If no Event structure executes promptly to handle an event and front panel locking is enabled, the user interface of the VI may become unresponsive. If this occurs, click the Abort button to stop the VI. You can disable front panel locking by right-clicking the Event structure and removing the checkmark from the Lock front panel until the event case for this event completes checkbox in the Edit Events dialog box. You cannot turn off front panel locking for filter events.

You are probably right about compiler optimization for unreachable code. Changing the compiler optimization level most likely has no effect because it is still unreachable and therefore not included.

Edited September 3, 2021 by LogMAN

[bjustice]

Today I learned.  Thanks Logman

[jacobson]

Even though we know we will never go to the True case, I doubt LabVIEW would ever be able to determine that and properly remove dead code. It would require LabVIEW to know that the timestamp output of a primitive converted to a double will never be less than 0. If you wire a false constant into the case selector the VI won't lock up so it does work in that instance.

I remember running into issues with events being queued when the VI is only reserved to run by (accidently) embedding VIs that weren't running into subpanels. The VI isn't running but clicking anything can still enqueue events and cause everything to lock up.