LabVIEW injects bug in working code

[Fedor]

I just spend good portion of a day debugging a problem with the code that was working fine just last week. Turns out one of the call parent method VIs was replaced with call to same method VIs when I used save vi menu. This obviously created an infinite recursion, hanging up the code. LabVIEW version 2024 Q1.

Did something like this happen to anyone here before? Should I wipe out NI products and do a clean re-install? 

[Yamaeda]

That sounds strange. If it's the root object it makes sense, but it should break or flag, I think.

[wiebe@CARYA]

---

@Yamaeda wrote:

That sounds strange. If it's the root object it makes sense, but it should break or flag, I think.

---

It's perfectly legal to do this, even if the method isn't reentrant.

Child A method A could call Child B method A, and this is allowed. Since the two methods are different VIs, this is OK even if method A isn't reentrant. This is and should be allowed.

Since the method is dynamic dispatch, Child A method A could call DD method A and this is still allowed.

However, if Child A method A calls Child A method A and method A is not reentrant, you get a run time error which is horrible. 

If Child A method A calls Child A method A and method A is reentrant, you get infinite recursion. Also horrible. 

I've made this mistake (call method in stead of call parent) many times. I've never been able to blame LabVIEW...

I even ran into the scenario where I tested the code successfully and the next day discovered the mistake.

I'm not ruling out it's something LabVIEW did, but every time I ran into this I eventually concluded it was my mistake.

If you're convinced LabVIEW did this, the only way to proceed is to find a way to reproduce this.

[Fedor]

I am sure I did not replace call parent in the method  in question since I have not opened that particular method in couple of years - that's why it took so long to find out what part of the project is  hanging. The preceding project commit from few days back is fine.  

On the side note, the application builds based on this project often require to clear the LabVIEW cache prior to build, or the build throws an error. There was a mention of this type problem of problem on the forums.

[wiebe@CARYA]

---

@Fedor wrote:

I am sure I did not replace call parent in the method  in question since I have not opened that particular method in couple of years - that's why it took so long to find out what part of the project is  hanging. The preceding project commit from few days back is fine.  

---

In that case, it looks indeed like LabVIEW did it. More importantly: this opens a (small, tiny) opportunity to try and reproduced and reported the problem.

---

@Fedor wrote:

On the side note, the application builds based on this project often require to clear the LabVIEW cache prior to build, or the build throws an error. There was a mention of this type problem of problem on the forums.

---

That cache sure turns out to be a double edged sword...

I never noticed VIs changing automatically related to the cache, but it turns out to be really complex in practice so who knows what side effects there are. Esp. combined with .vims the cache seems to break often.

[Yamaeda]

Btw, did this happen with a LV upgrade? 

[Fedor]

---

@Yamaeda wrote:

Btw, did this happen with a LV upgrade? 

---

No, LV was not upgraded

[wiebe@CARYA]

Something must have triggered this...

Of course it could potentially be anything, ranging from OS, SCC, LV, VIs... But it can be narrowed down to something that specifically happened this time and not the previous years.

Given that you seem to practice proper SCC, any change you know or can guess what you did?

If not, I think there's not much anybody can do. Fixing a bug that isn't reproducible is incredibly hard.

Code changing overnight is bad, esp. if this doesn't trigger a edit or compile time error.

[Ettepet]

---

@Fedor wrote:

I just spend good portion of a day debugging a problem with the code that was working fine just last week. Turns out one of the call parent method VIs was replaced with call to same method VIs when I used save vi menu. This obviously created an infinite recursion, hanging up the code. LabVIEW version 2024 Q1.

Did something like this happen to anyone here before? Should I wipe out NI products and do a clean re-install? 

---

When I tried to move our company's software from LV2018SP1 to LV2024Q3 (and beyond) I noticed that at some point a softlock had been introduced in Labview when using "Create SubVI" (from the pull-down menu).

When you immediately save the resulting code everything seemed to work fine.  Only when you do "Create SubVI" and - before saving - first re-assign in- and outputs, you run the risk of soft-locking your development environment.

Together with some other bugs I bumped into my assessment was that changes had been introduced into Labview without proper testing all common scenarios.  I also noticed that very few issues were being reported back to NI.  Most experienced Labview programmers seem to be sticking to older versions.

Because you suggest there was a change under the hood done by NI, the issue you bumped into might be similar. (recent changes, with insufficient testing by NI, and perhaps too few people using this newer version)