Describe the bug
When compiling with MinGW 9 (GCC 11.2) for a debug build, calling AVX2 functions trigger a segfault. Seems to be related to #1119 but is still present under 3.1.0.
To Reproduce
Any simdjson code that runs on AVX2 and is compiled with MinGW in debug will show the same behaviour. The code linked in #1119 will still show the same result. To be more specific, this bug was found by testing my fastgltf library with MinGW and seems to always be reproducible. Though note that this does not happen at all as soon as any optimization is applied.
Trying to load Sponza with the fastgltf_gl_viewer example of my library I always get a segfault at simdjson::haswell::simd::base8_numeric::load. Using a debugger I was able to verify that values was 0x258348ff6e0 (which seems like its 32-byte aligned) and was pointing to the beginning of my JSON string and looked perfectly valid.
I've gone ahead and disassembled the function that ultimately faults the program, with the arrow indicating the precise line it faults at:
https://gist.github.com/spnda/bb2acdb94bdbe652a7dfa8fd2f04f5a4
Interestingly, this is faulting at vmovdqa which is an aligned load, even though the actual C++ code is calling _mm256_loadu_si256 which is an unaligned load.
Furthermore, I've noticed that it sometimes instead faults in the splat function, which (by reading the disassembly) seems to load the value from the frame pointer because GCC inlined the function. However, it, again, uses vmovdqa to load the value from an address that is not aligned to 32-bytes, causing the segfault. This seems to be related to this SO post, where the compiler doesn't properly align _mm256i variables on the stack causing segfaults when loading a local variable.
So perhaps I should instead forward this to the GCC/MinGW people? The GCC ticket linked in the aforementioned SO post is actually still open after multiple years.
Also, is it maybe possible that I can check if the compiler is from MinGW and then just disable the AVX{,2} implementations using macros?
simjson release
- simdjson 3.1.0
- gcc.exe (GCC) 11.2.0 (from CLion's MinGW install)
- Windows 11
Describe the bug
When compiling with MinGW 9 (GCC 11.2) for a debug build, calling AVX2 functions trigger a segfault. Seems to be related to #1119 but is still present under 3.1.0.
To Reproduce
Any simdjson code that runs on AVX2 and is compiled with MinGW in debug will show the same behaviour. The code linked in #1119 will still show the same result. To be more specific, this bug was found by testing my fastgltf library with MinGW and seems to always be reproducible. Though note that this does not happen at all as soon as any optimization is applied.
Trying to load Sponza with the
fastgltf_gl_viewerexample of my library I always get a segfault at simdjson::haswell::simd::base8_numeric::load. Using a debugger I was able to verify thatvalueswas0x258348ff6e0(which seems like its 32-byte aligned) and was pointing to the beginning of my JSON string and looked perfectly valid.I've gone ahead and disassembled the function that ultimately faults the program, with the arrow indicating the precise line it faults at:
https://gist.github.com/spnda/bb2acdb94bdbe652a7dfa8fd2f04f5a4
Interestingly, this is faulting at
vmovdqawhich is an aligned load, even though the actual C++ code is calling_mm256_loadu_si256which is an unaligned load.Furthermore, I've noticed that it sometimes instead faults in the
splatfunction, which (by reading the disassembly) seems to load the value from the frame pointer because GCC inlined the function. However, it, again, usesvmovdqato load the value from an address that is not aligned to 32-bytes, causing the segfault. This seems to be related to this SO post, where the compiler doesn't properly align_mm256ivariables on the stack causing segfaults when loading a local variable.So perhaps I should instead forward this to the GCC/MinGW people? The GCC ticket linked in the aforementioned SO post is actually still open after multiple years.
Also, is it maybe possible that I can check if the compiler is from MinGW and then just disable the AVX{,2} implementations using macros?
simjson release