string initial value difference between execute steps in process and external instance of LabWindows/CVI

[Young_Chris]

Hello,

I am curious about what I am seeing using TestStand 2013/LabWindows 2013 in regards to initial string values in TestStand when executing the steps in process or an external instance of LabWindows/CVI.  

I have a string value test step(CVI) that is used to verify a character array stored in a EEPROM.  I pass the Step.Result.String into CVI by reference.  I then read the charater array from the EEPROM into the string (Step.Result.String).  The string is then compared against the limit as specified withing the test step.

When I run this test step with execute steps in process selected from the LabWindows/CVI Adapter Configuration popup it appears that the memory allocated to the string is filled with null characters.  Which is what I would expect.  

When I run this test step with execute steps in an external instance of LabWindows/CVI iselected from the LabWindows/CVI Adapter Configuration popup it appears that the memory allocated to the string is filled with something else.  Which is not what I would expect.  For instance what I see in memory is that the first characher is a null byte but the remaining bytes are some other values as shown below:

00 F0 AD BA 0D F0 AD BA 0D F0 AD BA 0D F0 AD BA 0D F0 AD BA 0D F0 AD BA 0D
F0 AD BA 0D F0 AD BA 0D F0 AD BA 0D F0 AD BA 0D F0 AD BA 0D F0 AD BA 0D F0 ... 

In my code I make sure to write a null character in the location following the charater array I just wrote into the string so I have no problems with the test working correctly.  I did remove writting the null character from my code and was able to verity that the test passes when executing steps in process and fails when executing steps in an external instance of LabWindows/CVI.

The returned string contains what I wrote to it and then the rest of the string is filled with the values that are in the memory space allocated to the string.

Here is my Question:  Is this the expected behavior for initial string values in TestStand between the two types of step executions?  

Thanks,

Chris Young

[dug9000]

In general, in most programming languages, when you allocate a block of memory there is no guarantee what is stored in that block of memory unless you clear it out yourself or call a special allocator which does so. The reason for this is that in most cases, especially for large blocks of memory, it would be an unnecessary waste of cpu cycles because most likely the code allocating the memory is about to fill it in with its specific data anyway.

The one thing that you can count on is that when teststand passes you a string that it will be a valid null terminated string, and it is in both cases in your example. That is why the first byte is zero even in the out of process case. Thus the part of the memory that counts is the same in both the in process and out of process cases, they are both giving you empty strings. You are not supposed to access any memory after the null termination character when reading a string.

Similarly, when you write your string to that buffer, you should also be null terminating it in all situations.

So basically, in summary, it is expected behavior, and you are actually getting the same value for the string in both in process and out of process cases, both are giving you empty strings. You should not be looking at memory past the null termination character. When you write a new string to the buffer you should always be null terminating it (as well as making sure it fits within the space allocated for the buffer).

Hope this helps explain things,

-Doug

[Young_Chris]

Hi Doug,

I aggree with what you you have written.  I appologize, it seems that my question was not clear.  

What I meant to ask was, "Is it expected(or known behavior)  that TestStand appears to be initializing the memory location for strings differently based on the type of step execution?"

Thanks,

Chris

[dug9000 · Accepted solution]

In general teststand is not initializing the unused portion of string buffers so it is expected that the memory values after the null termination character will be different, and possibly on every call. If you happen to be getting zeros after the terminating null character that was likely due to chance (i.e. the memory that was allocated just happened to already have zeros in it) or perhaps a debug setting you might be using in the Visual C runtime (if you are debugging the process in visual studio or changing any visual C runtime heap settings). TestStand is not initializaing the memory after the null termination character in either use case (I checked the code).

-Doug

[Young_Chris]

Thanks Doug 🙂