Race Conditions revealing themselves years later?

[Broken_Arrow]

Hello all.

I would like to ask the folks that have many years experience in LabVIEW, maintaining legacy LabVIEW programs, if they have seen anomalies pop up years after deployment. Specifically, issues where legacy programs written on older LV with older Windows operating systems have been incrementally (or suddenly) updated.

I have an old, large, gangly program (not written by me, not that my code isn't gangly, but I digress) that has served its purpose for 10+ years, but we have noticed that the latest update (Win10/LV18) will freeze and act erratic after several days of operation, whereas the old program (let's say for sake of argument LV 8.5 / Windows NT) doesn't do that.

We've been down the driver/hardware compatibility rabbit hole and we just don't think anything is "wrong" there, or it wouldn't work as well as it does for 3 or 4 days straight until the issues pop up.

I'm sorry I can't give more specific information, other than to say the hang appears to be from an infinite wait state.  I'm just looking for advice from the "old" heavy-hitters of what kind of issues they've seen like this.

[RTSLVU]

I know this does not solve your issue but... There is something to be said about not fixing things that are not broken. 

Why upgrade the OS on a test system that is running fine?

We have test systems built a decade ago with computers still running Windows XP in our lab because they still work. 

[Broken_Arrow]

---

@RTSLVU wrote:

I know this does not solve your issue but... There is something to be said about not fixing things that are not broken. 

Why upgrade the OS on a test system that is running fine?

We have test systems built a decade ago with computers still running Windows XP in our lab because they still work. 

---

VERY good point. Let's just say we "had" to upgrade - didn't have a choice. I certainly would not have suggested touching this stuff.

[crossrulz]

Well, I must point out the obvious first...

1. Local and/or Global variables - I inherited a test system that used locals to pass data between loops and it worked perfectly...on a P4 processor.  Took it to an Intel Core 2, and only every 5th data point was saved.  I rewrote that code to use queues.

2. Functional Global Variables - These are a little less obvious since they immediately look like they are protecting against race conditions, but if they are just "get" and "set", you really just have a slower Global Variable.  A Look At Race Conditions

Since you are making such a large jump, I am willing to bet you are running into issues from going to a multi-core system, or at least more cores.

[altenbach]

Changing LabVIEW version as well as hardware can expose latent race conditions in poorly written code.

Changes in the number of cores can make a difference as has already been mention. (even hyperthreading and core architecture differences). Back in NT days, single core processors were common. Now many things can execute concurrently. Maybe some of the hardware interaction could be set to run in the UI thread for testing?

Let's not forget that the LabVIEW compiler does a lot of optimization that can change the execution order when no explicit data dependency exists. Even if it works 100% in one version does not guarantee that it will work in the next version if there are race conditions.

[UliB]

Long time ago I took code from LV8.5 to LV2012 and learned that a simple 'To Unsigned Byte Integer' does not behave the same way in these versions of LabVIEW.

My old notes say that if 'Not A Number' (double) gets converted to U8 in LV8.5 the result is 0, in LV2012 the result is 255.

A simple change, but if you have such a change in a calculation for a wait time .....

[Kyle97330]

It's already been mentioned that newer PCs are faster and have more cores, so timing on things can change.

One other area that newer OSes are fairly different in compared to old ones is security.  If I had to guess, that may have been the reason you were forced to upgrade.

As such, anything that needs authentication of some sort, or any file read/writes, especially to network locations, can take longer or have problems because the authentication takes longer or the antivirus/firewall adds delays.

You could try turning off antivirus/firewalls temporarily and see if that moves your software back to stable, or see if you can do local file writing instead of network file writing temporarily.  While those probably wouldn't be permanent fixes, they'd at least point you in the right direction.

[Broken_Arrow]

---

@crossrulz wrote:

Well, I must point out the obvious first...

1. Local and/or Global variables - I inherited a test system that used locals to pass data between loops and it worked perfectly...on a P4 processor.  Took it to an Intel Core 2, and only every 5th data point was saved.  I rewrote that code to use queues.

2. Functional Global Variables - These are a little less obvious since they immediately look like they are protecting against race conditions, but if they are just "get" and "set", ...

---

The program has tons of Locals

The program has tons of Globals

But moreso, the program has tons of FGs with just Set & Get. It seems this code was written when FGs were all the rage. "Look mom, no Globals". Yeah rite.

The code is full of asynchronous parallel structures, and a complex XControl, which is an asynchronous parallel structure with land mines.

[billko]

---

@Broken_Arrow wrote:

---

@crossrulz wrote:

Well, I must point out the obvious first...

1. Local and/or Global variables - I inherited a test system that used locals to pass data between loops and it worked perfectly...on a P4 processor.  Took it to an Intel Core 2, and only every 5th data point was saved.  I rewrote that code to use queues.

2. Functional Global Variables - These are a little less obvious since they immediately look like they are protecting against race conditions, but if they are just "get" and "set", ...

---

The program has tons of Locals

The program has tons of Globals

But moreso, the program has tons of FGs with just Set & Get. It seems this code was written when FGs were all the rage. "Look mom, no Globals". Yeah rite.

The code is full of asynchronous parallel structures, and a complex XControl, which is an asynchronous parallel structure with land mines.

---

reminds me of this little gem:

[Yamaeda]

Upgrading LV has caused this for me. That's really not surprising, as LV will recompile and reoptimize, and if you had some 'loose ends' there's no guarantee for what will be the result.

In my case some locals changed the read order (one of my first inherited projects), so I had to come up with some better solution.