LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reentrancy bug in LabVIEW 2024 Q3 with backsaving

Got a weird one: the attached project was saved in LabVIEW 2024 Q3 with the save version set to 2021 (so it can open in 2021).

 

If you extract and open the project in 2024 Q3, then run "Run Me.vi", the indicator populates with 4 clone names and no error (expected result). If you then open "Reentrant subVI.vi" and rerun "Run Me.vi," again 4 clone names and no error. If you then edit "Reentrant subVI.vi" by moving a node (which deletes any clones that exist) and rerun "Run Me.vi," the same thing happens (no bug yet). If you then save "Reentrant subVI.vi" and rerun "Run Me.vi," you get 4 errors and no clone names. If you pay attention you'll notice it's actually the reentrant original running 4 times in series: no clones are allocated or called.

 

If you do this in LabVIEW 2021, you get the same result before and after saving (expected result).

 

When I set the save version for the project to 2024 and resaved the 2 VIs, the bug persisted until I closed and reopened the project, then the behavior stopped: when the save version is equal to the editor version the bug seems to go away.

0 Kudos
Message 1 of 15
(433 Views)

Is this the same problem as this? https://forums.ni.com/t5/LabVIEW/Question-about-Implicit-Multithreading/m-p/4335568#M1270751

---------------------------------------------
Certified LabVIEW Developer (CLD)
0 Kudos
Message 2 of 15
(360 Views)

@Frozen wrote:

Is this the same problem as this? https://forums.ni.com/t5/LabVIEW/Question-about-Implicit-Multithreading/m-p/4335568#M1270751


I don't think so. That is about OS threads, this issue is about when and whether clones are allocated and called. I think anyone who has worked with reentrant VIs would be shocked to see the original VI run at all when it is reentrant and called as a normal subVI. If the compiler just did a crappy job of optimizing, it would give one clone in this circumstance, instead it gives 0.

0 Kudos
Message 3 of 15
(355 Views)

This is now bug #2937381

Message 4 of 15
(274 Views)

I've been struggling with this same issue for the last week+... so glad to see I'm not the only one. In my case, I'm using LV 2024 app with VIs saved as LV 2023 files.  I didn't realize there was a connection related to the app version not matching the save version, but will try to confirm this on my end as well.  It makes applications do really weird things when sometimes the reentrant VIs are actually cloned and sometimes (seemingly at random) run as if it was non-reentrant and has shared state across all instances.  

0 Kudos
Message 5 of 15
(265 Views)

It would be very beneficial if you could forward code to ni with the specific issue you see. Just in case your issue is not a 100% overlap of that one here.

Actor Framework
0 Kudos
Message 6 of 15
(242 Views)

OK, where would I forward it?  Attach to this thread?

 

Ultimately the demonstration should be as simple as making a child VI reentrant and setting up a parent VI to run it a couple of times using the Call Async and observing that sometimes it is called as a clone, and other times it's not (e.g. it's just called as a traditional VI with shared state across the callers) depending on some sequence of editing, saving (as older version), and running the parent.  

 

I have also seen the issue with Actor Framework actors not behaving correctly, probably for the same reason (because under the hood, AF should be calling multiple reentrant Actor Cores asynchronously as clones but is instead calling the same instance).

 

As mentioned in the original post, this appears to happen when the editor/app is 2024 but the save version is older.  This is the case with my project as well, but I have not yet found time to confirm that if I update the save version to 2024 then the issue goes away.  The issue does NOT occur when I use LV 2023 app to run VI files saved in 2023 format (which is how I'm able to continue my work now unimpeded by this issue).

0 Kudos
Message 7 of 15
(227 Views)

You can file a bug report from your ni account. After describing your issue you can optionally add some code.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q0000019gX9CAI&l=de-DE

Actor Framework
0 Kudos
Message 8 of 15
(194 Views)

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?

Message 9 of 15
(174 Views)

You can explain yourself by filing a service request/bug report. This is the way to go.

Actor Framework
0 Kudos
Message 10 of 15
(157 Views)