LV8.01: Bug when casting in "build array"

[C.Horn]

Hi,
I think I found a serious bug in the "build array" function in LV 8.01. When automatic casting  is done (i.e. if you wire different data types to the inputs) this can result in data corruption or a crash of LV.
Wether this happens depends on the exact configuration of the inputs for the "build array" function. In the attached example VI it results in a crash of LV. In a much more complex numerical simulation that I did it resulted in incorrect numerical results because some array elements were overwritten with wrong values.
I tested this also in LV 6.1 and 7.1 and both are NOT affected. We don't have LV 8.20 yet, so it would be interesting wether this bug is still in there.
Of course the solution is to manuallay cast the array elements before building the array.

Christian

[Will.D]

Confirmed in 8.2 as well.  This is kind've dangerous!  Glad you spotted it.

[johnsold]

Runs fine in LV 8.0.1 and 8.20 on Mac OS X (PPC).

Do you have an example where it produces incorrect results?

Lynn

[Norbert_B]

Christian,

sadly, the crash also occurs in LV 8.20.
Nevertheless, i found out that an explicit typecast infront the build array-function prevents the failure. It seems that the failure also depends on the representation of the number. I checked it for some time and it appears, that unsigned integers are more stable, nevertheless, it occurred there as well..... Maybe this info is already sufficient for you....
I passed the issue on to R&D.

hope this helps,
Norbert B.
NI Germany

[Ben]

"I passed the issue on to R&D."

Could you please post the CAR# for this?

Ben

[C.Horn]

@johnsold
Attached VI should demonstrate an example where incorrect results are produced (at least in LV8.01 and in WinXP). I don't know how much of the complexity is actually needed. I just rebuild the part of my VI where the error occured in a simplified way.

In the example a 3D array 5x5x100 is produced where only the first 5x5 page contains the correct data. All other pages contain only zeros.

In my program the result was even more subtle (and mean) because all pages where correct exept the last row of each page which contained zeros (instead of zeros and a single value in the last column). So the difference was minimal and the numerical simulation of a quantum mechanical system produced plausible results albeit different from the experiment. Fortunately we still had LV6.1 results that differed too.

@Norbert B.
The problem is not really finding the workaround, the problem is realizing that there is a problem and localizing it. I am working in science and publishing incorrect results is a pretty grave thing and nobody will believe me if I claim it was a bug in the programming language...

Christian

[C.Horn]

Next try to attach this...

[johnsold]

This also works OK on both LV8.0.1 and LV8.20 on Mac OS X (PPC). 100 identical pages with 1s on the diagonals.

Lynn

[Spex]

Hi all,

I reproduced the crash that started this post on my machine with 8.20.  This was reported to R&D (# 43Q7NJPT) for further investigation.  As mentioned above, a workaround for avoiding the crash is to manually coerce the integer datatypes to Complex Doubles using the To Complex Double primitive on the numeric pallette. 

I have not had a chance to test the second VI that produces incorrect results, but it sounds like another CAR.

[AdamKemp]

This was reported to R&D (#43Q7NJPT) for further investigation.