"Error illegal operation" Support for CPU's not supporting SSSE3 (not to b confused with SSE3) are broken (for no good reason).

[OSVidYapan-mirror]

This happens to me when i try to run the game binary.

Which means illegal operation in Turkish.
This often means the CPU doesn't have the instruction to run the app and PC lacks x86_64 v3
Its like this since version 1.4.4 and version 1.4.5 has the exact same issue
However compiling without modification works.
I only had to add this file to external/gamecontrollerdb from Github because for some reason it wasn't there.
(Latest release works)

gamecontrollerdb.txt

Also this is from directly git the latest release on release page 1.4.5 has the basis_univerisial, gamecontrollerdb and koishi directory empty which cannot build (again no architectural issue).

Edit: Some files missing issue in source code was my issue, because i forgot submodules.
I have recompiled without modifying at all and it works however this does not solve the problem of precompiled binary releases not working on x86-64 v2.

These are the builds that i compiled and this build should work on any x86_64 v2 CPU

The GIT release
taisei.zip

The 1.4.5 release
taisei.zip

Distro: Artix Linux
PC: Surface Go 1
CPU: Intel Pentium Gold 4415Y

[Akaricchi]

We build the release binaries for Linux with -march=core2, which is very conservative, it's a strict subset of x86-64-v2. We link all of our dependencies statically, and it's possible that some of the libraries are incorrectly configured to use hand-optimized asm code that is not compatible with your CPU.

To figure out what exactly is at fault, please perform the following steps.

1. Download the debugging symbols for the v1.4.5 release.
2. Extract the file src/taisei.dwarf from the archive, and place it in the same directory as the crashing taisei binary.
3. cd into that directory and run gdb taisei.
4. In the gdb prompt, run symbol-file taisei.dwarf. You should see a message like Reading symbols from taisei.dwarf....
5. Type run into the gdb prompt and press enter. The game should now run. Wait for it to crash.
6. Back in the gdb prompt, type bt, and paste the output here.

That should tell us which part of the code has a bad instruction.

---

Regarding the missing files in the source code: if you clone from git, you must use --recurse-submodules, or run git submodule update --init. If you're downloading a source tar archive instead, make sure to grab the right one. The one labeled taisei-1.4.5.tar.xz on the release page is what you need, it contains all the submodules. The one labeled "Source coded (zip/tar.gz)" is auto-generated by Github and should not be used, it's missing the submodules.

[OSVidYapan-mirror]

After running it this is what i get

---

#0 0x000000000190ff55 in mi_option_init (desc=)
at ../../subprojects/mimalloc/src/options.c:704
#1 0x00000000019109f7 in mi_option_get (option=mi_option_verbose)
at ../../subprojects/mimalloc/src/options.c:277
#2 mi_option_is_enabled (option=mi_option_verbose)
at ../../subprojects/mimalloc/src/options.c:324
#3 _mi_verbose_message (fmt=0x10d164c "process init: 0x%zx\n")
at ../../subprojects/mimalloc/src/options.c:541
#4 0x000000000190e1b3 in mi_process_init_once ()
at ../../subprojects/mimalloc/src/init.c:1099
#5 0x0000000001915c49 in mi_process_init ()
at ../../subprojects/mimalloc/src/init.c:1144
#6 _mi_auto_process_init () at ../../subprojects/mimalloc/src/init.c:1007
#7 mi_process_attach () at ../../subprojects/mimalloc/src/prim/prim.c:42
#8 0x0000000001ef6d51 in __libc_csu_init (argc=argc@entry=1,
argv=argv@entry=0x7fffffffe888, envp=envp@entry=0x7fffffffe898)
at /usr/lib/zig/libc/glibc/csu/elf-init-2.33.c:88
#9 0x00007ffff7c27a53 in __libc_start_main_impl (main=0x13d02a0

, argc=1,
argv=0x7fffffffe888, init=0x1ef6d00 <__libc_csu_init>, fini=,
rtld_fini=, stack_end=0x7fffffffe878) at ../csu/libc-start.c:343
#10 0x00000000013af8aa in _start ()
at /usr/lib/zig/libc/glibc/sysdeps/x86_64/start-2.33.S:120

---

Also thanks for submodule issue it took me long time to understand but now i know...

[Akaricchi]

Looks like a mimalloc problem, though I'm not sure what could cause it. Can you try building v1.4.5 with these options to see if that reproduces the crash? In the build directory: meson configure -Dforce_fallback_for=mimalloc -Dallocator=mimalloc, then ninja.

[OSVidYapan-mirror]

It didn't really error me and the game compiled succesfully (this building did not use -march=core2)

Again it only crashes with precompiled binaries...

Also -march=core2 does return this

This is what compiling screen looks like.

[Akaricchi]

Also -march=core2 does return this

-march is a compiler flag, not a meson one. You'd have to do something like this if you want to try it: meson configure -Dc_args=-march=core2 -Dcpp_args=-march=core2. Though I suspect it's not going to change anything. It might be related to the zig toolchain and/or the glibc version we're using.

Either way, I don't have access to any of the affected hardware, so I can't fix this properly. The only thing I could do is to disable mimalloc for Linux builds, but that's not even guaranteed to fix the issue. I guess I'll put this on the back burner for now, and maybe write a notice on the download page saying the build may not work on some older CPUs. These days the Flatpak build should be preferred anyway.

[OSVidYapan-mirror]

I have tryed both options at once....

And it also didn't fail...

---

BTW for some reason YES the flatpak and wine actually worked...
Which is weird because architectural problems aren't supposed to just work in containers (ex. flatpak)???

---

Tryed in other distros like fedora and it didn't work as well (but gave me even more clear same error).

If this doesn't get fixed i suppose i am gonna maintain those older CPU's myself at itch.io…

---

Also yes techinally (i know this issue the game requires libunibreak by now)…

[Akaricchi]

BTW for some reason YES the flatpak and wine actually worked...
Which is weird because architectural problems aren't supposed to just work in containers (ex. flatpak)???

They are compiled with different toolchains. This bug is probably specific to the Zig toolchain we're using to compile our Linux releases. It has nothing to do with containerization.

If this doesn't get fixed i suppose i am gonna maintain those older CPU's myself at itch.io…

Your binary is dynamically linked to your system's libraries. It's not going to work on any distro that ships different major versions of any of the linked dependencies, or an older glibc. It's also going to break when your distro updates any of those libraries to a newer ABI version.

What you see on your very last screenshot is what happens with mismatched library versions. Some distros have switched to libunibreak version 7, and many others are still on 6.1. They are not ABI-compatible, so a Taisei linked to libunibreak 7 is not going to run on a distro with 6.1, and vice versa. Our releases link most dependencies statically and target an old glibc to mitigate this problem.

[OSVidYapan-mirror]

Sorry for distrupting but i have tried the latest build (1.4.6) and got same results…

---

More debug details;

Tried to run the debug process and got this (probably same)

And this is the screenshot of a log file (from what i compiled) to show what extensions are not supported by my pc.

---

At this point i think i should test the precompiled binaries before closing this issue as "completed" or else days/commits would be wasted… (You can add zip file to this issue)

In the meanwhile, yes i confirmed that this works with a (very slow) CPU emulator and a different pc that has x86-64 v3 CPU (i have checked the log file at that pc and saw AVX and AVX2 was present but NEON was not)

In case you no longer want to deal with this issue please close this as "not planned" instead…