Anyone else having DVR/In-place-element structure bug (error 1556) in LabVIEW 2023

[sdusing]

Is anyone else having random 1556 errors when using DVRs/In-Place-Element structures in LabVIEW 2023 Q3?  We have a large application that's been working well in LabVIEW 2023 Q1 and suddenly upon updating, we're plagued with 1556 errors that are sometimes repeatable, but often not.  We eventually narrowed it down to two vi's that we were running and were able to reproduce the error. All we were doing was creating a DVR and calling an IPE (see the gif). Interestingly though, it's not that simple (otherwise I assume NI would have caught it before Q3 release). When I tried to recreate the exact code that produced the error, I was unsuccessful.  Maybe it was because some other code was open or ran before?  I'm guessing this is a bug in LabVIEW 2023 Q3 - can anyone else corroborate?

 

[JÞB]

I DON'T see two things that I would expect in that code:

• The Obtain DVR doesn't show the concurrent access glyph
• The IPE DVR Read node is not marked with a "Stomper" 

In theory, that might create a silly memory manager problem if the Data itself is not fixed sized or contiguous.  That would certainly explain why it would be insidiously difficult to reproduce and, since exact Memory Management is subject to change, why improvements in LabVIEW could uncover new behavior. 

You'd probably need a deep dive into the entire code by NI R&D to sort the exact behavior.  DETT might be useful to compare some performance changes.

[sdusing]

Hi Jay,

Thank you for the response. Apologies for my ignorance - you're using terms I've admittedly never encountered before.  Can you please help me understand what you mean by the following points?

• The Obtain DVR doesn't show the concurrent access glyph
  
  • Do you mean "New Data Value Reference.vi" instead of "Obtain DVR"?  Or are you referring to the read/write DVR nodes on the In Place Element Structure
    
    • Either way, I'm not sure why/where I would expect to see a concurrent access glyph. Can you explain what you meant by this or provide a screenshot?
• The IPE DVR Read node is not marked with a "Stomper" 
  
  • What is a stomper?

[JÞB]

Yes I meant New DVR Reference,  right-click it and it can be marked for concurrent read access.

On the IPE.DVR left node there is another right-click option to mark the access.  A stomper, in the DVR case, appears to be related to some memory allocation stuff that NI doesn't go into detailed details about.

Both right-click options are mentioned in the Help file and each adds a minor Glyph to the function on the BD.

What I think may be happening here is that the DVR itself is being copied at the wire branch.  You could test this by going to the older workingish version and sticking an "Always Copy" on either wire branch and see if the behavior becomes the same as the updated version. 

In other words, you might have been depending on undocumented behavior and discovered a bug fix rather than a bug.

[sdusing]

---

@JÞB wrote:

Yes I meant New DVR Reference,  right-click it and it can be marked for concurrent read access.

I'm not seeing a "concurrent read access" option in the right click menu 

---

On the IPE.DVR left node there is another right-click option to mark the access.  A stomper, in the DVR case, appears to be related to some memory allocation stuff that NI doesn't go into detailed details about.

---

I don't see an option on the left IPE.DVR node to mark the access... though I do see an option on the IPE.DVR left node to "Mark as modifier." Is this what you meant by "stomper"? This option seems to be a low level setting to highly optimize buffer allocations for improving runtime performance, but I'm not seeing anything that 1) would make this relevant to my example or 2) actually impact functionality/result in errors.

Found this post helpful for learning about this feature: https://forums.ni.com/t5/LabVIEW/Mark-as-modifier-in-place-of-structure/td-p/2028072

The right IPE.DVR node allows for parallel read only access, which I'm familiar with but wasn't using in my code since I did want to modify the data.

---

What I think may be happening here is that the DVR itself is being copied at the wire branch.  You could test this by going to the older workingish version and sticking an "Always Copy" on either wire branch and see if the behavior becomes the same as the updated version. 

---

I don't think I'm following.  My understanding is that a DVR is a pointer.  If you branch a DVR, LabVIEW would maybe make a copy of the pointer, but it's not going to make a separate memory location.

[JÞB]

OK you found both options I was looking for, not exactly where I disremembered them but.. Hey, there is no LabVIEW IDE on my  phone.

---

What I think may be happening here is that the DVR itself is being copied at the wire branch.  You could test this by going to the older workingish version and sticking an "Always Copy" on either wire branch and see if the behavior becomes the same as the updated version. 

---

I don't think I'm following.  My understanding is that a DVR is a pointer.  If you branch a DVR, LabVIEW would maybe make a copy of the pointer, but it's not going to make a separate memory location.

---

Let me try again.  Yes, I think that the DVR itself is being copied at the wire branch in the updated code.  If the data itself resizes in the IPE the memory manager could update the memory location that the pointer points to.  THIS SHOULD invalidate the pointer on the other wire branch and if it does, error 1556 is right there to tell us that this DVR copy is stale.

Had you used an AC on the wire branch in the original code you would likely have seen the DVR go stale when it should have but didn't because NI made a mistake that they just corrected. 

At any rate...you really should get the DVR out of the IPE back into your Functional Global Variable or better yet turn it into a fully functional Action Engine with an API containing: Init, Read, Update, and Close methods.  At which point, you really don't NEED a DVR because the AE IS THE DVR as soon as you disable debugging.

[sdusing]

Processing your last message... but what's an AC?

[sdusing]

For what it's worth, I know that the data size in the IPE isn't changing because the DVR is created with a cluster that contains 3 empty maps and in the IPE we set the value of the data to a cluster that contains 3 empty maps.  In other words, the DVR is created with the EXACT SAME DATA that we write inside the IPE.

It's also worth noting, that this behavior only started happening after running a different part of our codebase. When we closed out of LabVIEW and reopened just these vi's again, we couldn't get the error. But the 1556 error is still cropping up when we try to run our full application... it just changes when and where. For these reasons, I'm fairly confident it's a bug in the LabVIEW Q3 release.

[MikaelH]

This scares me a lot.
We are using OpenGDS reference classes everywhere and that are using the DVRs in many cases just in your example.
And we are just about to migrate from LV2020 to LV2023Q3 😬

[JÞB]

---

@MikaelH wrote:

This scares me a lot.
We are using OpenGDS reference classes everywhere and that are using the DVRs in many cases just in your example.
And we are just about to migrate from LV2020 to LV2023Q3 😬

---

There is another NI Forum board you should bring this up for discussion on.  I don't have access at this time 😒

If nothing else,  at least try stuffing an Always Copy in your existing code as a test.