MEMCOPY UDT String Corruption

[Bolt]

I have a UDT memory block of 2048, with a String, Unsigned Byte, Bit, Signed DWord, Unsigned Word, as its contents. I copy a 6 character string into MyBlock0.String (.Length = 6, .MaxLen = 8 ), and it works fine. Later, I copy MyBlock0 to MyBlock1, Number of source elements 2047.

Looking at my data, when the data is in MyBlock0.String, it's properly formatted, etc. When it's moved to MyBlock1, MyBlock1.String shows <empty string> and MyBlock1 in multi-line view shows String(!BAD!Max(0)Len(0)CStringNestedStructStatusValue::GetAsStringArrayFromBuffer). All the other elements are still formatted correctly. What can I do to fix this? OS is 2.9.6 but I don't really care to update firmware via VPN, the connection to site has been spotty as of late.

If I manually re-enter the value into MyBlock1.String, it does display the correct value in MyBlock2.String after the MEMCOPY occurs.

[franji1]

The .MaxLen members of the .String member of your UDT are getting corrupted somehow.

You state "copy a 6 character string into MyBlock0.String".

How do you do this?

[Bolt]

I receive a JSON string from another BRX. This BRX runs a JSONPARSE and outputs the string into MyHeap.String, (also .MaxLen = 8 ) which is then used in the process.

When it comes time to copy the data to MyBlock (for historical/reporting purposes) I run a MEMCOPY from MyBlock0 to MyBlock1. Perform a MEMCLEAR on MyBlock0 and start populating it again. A number of fields are copied using the COPY instruction, including MyHeap.String -> MyBlock0.String.

Looking at MyBlock1-2047.String.MaxLen, they are all set to 0. If I manually write a string back to it, it reverts back to 8.

Writing all this out, it brings back memories to a previous project I had a similar issue with, I think MEMCLEARing a UDT with a string was the problem. However, I can't find a post here or in my email where we determined that, and what the version window for the bug was.

[Bolt]

I found an email from Greg from 23 months ago where he did determine the MEMCLEAR was corrupting the String.MaxLen value. I have removed the offending instruction and cleared out the necessary UDT fields manually. It looks like the operators are done for the day, so I won't get any new data to try it on until tomorrow, but I bet that fixes it. Sorry for the repetitive problem, I guess I had already forgotten about that DmD nuance...

[franji1]

Looking at MyBlock1-2047.String.MaxLen, they are all set to 0. If I manually write a string back to it, it reverts back to 8.

This is definitely the corruption.  Please figure out what is causing that so we understand the issue.  Don't just "make it work" - because you are probably not the only person who has seen/will see this.

That .MaxLen member across all the block and heap items  should be 8 and should always be 8.  Let us know what instruction(s) are causing it to be 0.  If the MEMCOPY of the heap item to the block element 0 makes the MyBlock0.String.MaxLen 0, figure out why the MyHeap.String.MaxLen is 0.

Thanks!

I checked back in February 2023, and this was an issue with MEMCLEAR that we fixed in the firmware in 2.10.  It may have been fixed in a version of firmware for 2.9 (firmware o/s version 2.9.9) that shipped that month.

What version of firmware are you using?

[Bolt]

Well, I "made it work", and the corruption issue started plaguing MyHeap.String (which I found extra odd...). The site's internet connection was fairly stable that day, so I risked a VPN firmware update from 2.9.6 > 2.10 and all problems went away, and I removed the workarounds and it stayed stable.

Yes, Greg identified the issue via email with me on 1/31/23. Sorry for the confusion, I quickly checked my emails but didn't see this pop up as I was initially approaching the unknown issue from a different angle at that time.

Thanks!

[franji1]

Glad you figured it out!!