Reentrancy bug in LabVIEW 2024 Q3 with backsaving

[Nate@UT]

Thanks.  Filed new Service Request 03364720 echoing the behavior reported in this thread. 

[avogadro5]

---

Nate@UT wrote:

I've downloaded the OP's example project and confirmed that the described behavior is the exact same as the one I've been struggling with (I used 2023 files and 2024 app). 

No need to file a redundant bug report or post different code.  Rather, I'd just like see NI provide a fix for it ASAP... is there any way to "upvote" on the existing bug report?

---

NI is really opaque about this stuff, I didn't get a link to an issue page or a fix date or anything, just the number. And if I hadn't chosen to post it, you wouldn't know it was a confirmed bug.

[Yamaeda]

Maybe i misread/misunderstood, but is it the same behaviour if you do a manual "save for previous" or just the automatic version?

[Nate@UT]

I have confirmed that the bug happens if both cases if you either:

a) create a reentrant VI in LV2024 and then manually back-save to a v2023 file, or

b) open a reentrant VI which was originally created and saved in LV2023 and run it in LV2024.

The issue happens when you've modified and saved the 2023 reentrant VI from within LV 2024 editor, but haven't yet closed the project and reopened it.  If you open the project without making modifications in the reentrant VI, the behavior is correct.  But that correct behavior disappears as soon as any modification is made and the VI is re-saved. 

[Quiztus2]

It also happens when opening 23 code in the 24 IDE and doing a mass compile. I didn't touch anything before mass compile.

[avogadro5]

---

@avogadro5 wrote:

This is now bug #2937381

---

Seems to be fixed in 2025 Q1 despite not showing up on the bug fixes list https://www.ni.com/en/support/documentation/bugs/25/labview-2025-q1-bug-fixes.html.

[Nate@UT]

Just updated to LV dev environment 2025 (including recent patch) late last week and had the issue recur again this morning with a VI back-saved as 2023; unfortunately this issue is not fixed, or else another one with very similar behavior has been created.  

[Darren]

Nate, are you able to share code with me that reproduces the issue? Because we had multiple examples in-house at NI that reproduced the bug in LabVIEW 2024 Q3, and they are all working properly in LabVIEW 2025 Q1.

[Nate@UT]

Hi @Darren, I appreciate the response.  The application where I continue to observe this behavior is in a large & complex project with a lot of dependencies plus proprietary code which would be difficult to share, and I'm not sure when I will have time to circle back and strip it down (or build it from scratch) into a minimally reproducible example.  The application involves dozens of Actor Framework Actors running concurrently so there is a lot of reentrant VIs involved.  Often multiple instances of a specific Actor are launched.  The application works flawlessly when running in LV 2023 as well as when running in LV 2025 with no edits made yet... but after editing & saving a reentrant VI (such as an ActorCore) from within LV2025, a behavior starts occurring where the first call into that ActorCore VI works OK, but the second call hangs as it's no longer a reentrant "clone".

[Darren]

Thanks for the additional details, Nate. That definitely sounds like the same bug, but as I mentioned, we currently have no way to reproduce it in-house in LabVIEW 2025. If you (or anyone else reading this thread) can eventually share code with me that exhibits the bug in LV 2025, that would be extremely helpful.