You are overflowing your stack by allocating such a large array statically, and that is the reason for the segmentation fault. The code itself is fine, if you lower your buffer size or allocate it on the heap somewhere, it’ll work.
You can also work around the stack size limit by running something like ulimit -s unlimited before executing your program, but I think reducing your stack size from within the program is the better idea.
It depends on your default stack size limit, how the compiler lays out the stack and what your program is actually doing.
For me on the default value, that’s 8192K, which is only slightly over your buffer size, and under that limit it segfaults. If I lift the stack size limit, it works with 40k x 512 boolean strings as expected.
For you it may have worked before because the stars aligned and the compiler laid the stack out differently, with different alignments or your program not happening to smash through the limit, but here it does not. 81920000 bytes for a single stack object is dangerously close to the default limit of 8388608 so you are playing with fire either way.
Because of the stack overflow, the code is jumping to garbage, triggering the illegal instruction. You can increase the stack size with Build.Step.Compile.stack_size.
Whether you will crash or not is not directly related to the size of the buffer. If you allocate a huge buffer but never write beyond the stack limit, you won’t crash. Therefore, if you called this code with less data or if the stack size was bigger, you might not get a crash. Note that the default stack size on Linux is 10x bigger than Windows, so this could explain why it didn’t crash before.