11-20-2024 05:11 AM
Hello LV community
I have a bug that causes LabVIEW to crash. This happens demonstrably with LV2023 and LV2024, with 32bit and with the 64bit version. LV2018 does not have this bug. I could not test other versions. The crash occurs without a warning or error message. The crash occurs when writing a 2D variant array to a file. To do this, the 2D variant array must be passed to a sub-VI. Transferring the data by reference works. The decisive factor is the changing size of the array. The crash occurs when switching to an empty array. I also have a solution for this: the empty array must be intercepted. I also have a test program with the solution. The error has already been reported but not yet published. In case anyone else encounters this problem, I will make it public here.
11-20-2024 05:22 PM - edited 11-20-2024 05:38 PM
Using 2024Q3 (32bit, community), I cannot get it to crash, so try patching if you are not on Q3 yet.
(If the crash occurs when trying to write an empty array, what exactly do you expect?)
(Of course I am totally puzzled about the purpose of this entire exercise. How useful is a binary file containing a 2D array of variants? (and how would it look if these variants also have attributes!) I am also seriously objecting against these pyramids of stacked sequences and all these unnecessary local variables.)
11-20-2024 05:52 PM
As said, I cannot get it to crash in Q3, even if I set x=y=0.
@altenbach wrote:
I am also seriously objecting against these pyramids of stacked sequences and all these unnecessary local variables.)
Here are some ideas how the code could be cleaned up. only one local variable. I am not sure why you have that wait frame. Should not make a difference.
11-21-2024 12:06 AM - edited 11-21-2024 12:11 AM
@robotroner wrote:
Hello LV community
I have a bug that causes LabVIEW to crash. This happens demonstrably with LV2023 and LV2024, with 32bit and with the 64bit version.
Yes, I can confirm the crash in LabVIEW 2024 Q3 Professional (v.24.3.2f2) for both 32- and 64-bit versions. Was able to reproduce three times.
This is how it looks (apologies for the screenshot in German) in the 32-bit version:
Technically, it is an Exception that occurred in tdcore_24_3.dll
Access violation at address 0D:
I ran the 64-bit version then under a debugger (twice), and indeed, it happened internally in LvVariantFlatten(), so it is definitely related to Variant.
DebugInfo for NI under Spoiler:
An interesting fact is that the fault address differs from run to run. Now rdi is 0x502, and the attempt to access rdi+10h (meaning 0x512) caused the "boom"(previously it was 2a2):
This is clearly a bug; the application should not crash in this manner under any circumstances. You can't 'fix' this, you can only 'avoid' it with kind of workaround.
Crash dump for NI in the attachment.
11-21-2024 12:21 AM - edited 11-21-2024 12:24 AM
Interesting. So what's different? I cannot get it to crash, even if I set x and y to zero forever in the original code.
(Since I obviously cannot reproduce the problem, I cannot debug further. One thing I might otherwise try would be to place an "always copy" on the variant wire in that particular case.)
11-21-2024 01:21 AM
The change between an array with at least 10x10 fields and 0x0 is crucial. Let the program run for a few seconds and change the sub_mode. A permanent output with an empty array does not cause a crash.
NI has been able to reproduce the error, but does not yet have a solution.
11-21-2024 01:49 AM
@altenbach wrote:
Interesting. So what's different?
I don't know, may be Community Edition is not affected at all (I haven't it in my hands to test). Anyway happened on both Windows 10 22H2 v.19045.4780 and Windows 11 23H2 v.22631.4460 with or without Hyperthreading enabled (sometimes HT caused such crashes) on different CPUs - i7 as well as Xeon.
For the test I simply run for few seconds "OK" version", then "Crashed". Screen recording in the attachment.
11-21-2024 02:52 AM
And this happened not only in Development Environment, but also in the Run-Time.
But in Run-Time crashed in lvrt.dll:
Faulting application name: Application.exe, version: 1.0.0.0, time stamp: 0x66f3ffc8
Faulting module name: lvrt.dll, version: 24.3.2.4002, time stamp: 0x66f40077
Exception code: 0xc0000005
Fault offset: 0x0000000000ae7fca
Faulting process id: 0x8a20
Faulting application start time: 0x01db3bf1bc837ff3
Faulting application path: C:\Users\Andrey\Desktop\builds\crash_test\crash_test\Application.exe
Faulting module path: C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\2024\lvrt.dll
Report Id: 99bb21a7-5577-4b9e-bc62-8df5bc519c20
Faulting package full name:
Faulting package-relative application ID:
WinDbg: