Open hhyyrylainen opened 1 year ago
Thanks for the detailed report. I hadn't tried the Mono build recently, but just did on my distro (Mageia 9, development release fairly up to date on packages) and I can reproduce the crash too.
Running kernel 6.3.3-desktop-1.mga9 and glibc-2.36-40.mga9. I'll get a stacktrace.
Compiled from a810c8c5f681e76d96d8b461ee6e173c094aa2e5 (basically the same as 3.6-beta2):
Mono: Log file is: '/home/akien/.local/share/godot/mono/mono_logs/2023-05-26_11.06.41_221943.log'
[New Thread 0x7fffb4bff6c0 (LWP 221976)]
[New Thread 0x7fffb530f6c0 (LWP 221977)]
ERROR: Mono: FATAL ERROR '* Assertion at /home/runner/work/godot-mono-builds/godot-mono-builds/mono_sources/mono/mini/mini.c:2259, condition `code' not met
(in domain , error)', ABORTING! Logfile: '/home/akien/.local/share/godot/mono/mono_logs/2023-05-26_11.06.41_221943.log'.
at: mono_log_callback (modules/mono/mono_gd/gd_mono_log.cpp:91)
Thread 1 "godot.x11.tools" received signal SIGABRT, Aborted.
0x00007ffff7b3f3ac in __pthread_kill_implementation () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff7b3f3ac in __pthread_kill_implementation () from /lib64/libc.so.6
#1 0x00007ffff7af0892 in raise () from /lib64/libc.so.6
#2 0x00007ffff7adc464 in abort () from /lib64/libc.so.6
#3 0x0000000001e84fa4 in GDMonoLog::mono_log_callback (log_domain=0x0, log_level=0x5098be8 "error",
message=0x8c0b710 "* Assertion at /home/runner/work/godot-mono-builds/godot-mono-builds/mono_sources/mono/mini/mini.c:2259, condition `code' not met\n", fatal=4) at modules/mono/mono_gd/gd_mono_log.cpp:97
#4 0x0000000001bdc2eb in monoeg_assertion_message ()
#5 0x0000000001bdc33a in mono_assertion_message ()
#6 0x00000000019d77bd in mono_codegen ()
#7 0x00000000019d9740 in mini_method_compile ()
#8 0x00000000019da332 in mono_jit_compile_method_inner ()
#9 0x00000000019cae81 in ?? ()
#10 0x00000000019cc21a in ?? ()
#11 0x0000000001afb0fe in ?? ()
#12 0x0000000001a79452 in ?? ()
#13 0x0000000001a79a65 in mono_exception_from_name_two_strings_checked ()
#14 0x0000000001a3ae14 in ?? ()
#15 0x0000000001a3e56e in ?? ()
#16 0x0000000001a3edff in mono_domain_create_appdomain ()
#17 0x0000000001e94823 in GDMonoUtils::create_domain (p_friendly_name=...) at modules/mono/mono_gd/gd_mono_utils.cpp:312
#18 0x0000000001e639b8 in GDMono::_load_scripts_domain (this=0x8b42090) at modules/mono/mono_gd/gd_mono.cpp:1028
#19 0x0000000001e5eb92 in GDMono::initialize (this=0x8b42090) at modules/mono/mono_gd/gd_mono.cpp:425
#20 0x0000000002287763 in CSharpLanguage::init (this=0x89728d0) at modules/mono/csharp_script.cpp:113
#21 0x0000000004adef1b in ScriptServer::init_languages () at core/script_language.cpp:170
#22 0x0000000001c2d8d8 in Main::setup2 (p_main_tid_override=0) at main/main.cpp:1612
#23 0x0000000001c29e37 in Main::setup (execpath=0x7fffffffda9f "/home/akien/Projects/godot/godot-3.x/bin/godot.x11.tools.64.mono", argc=0, argv=0x7fffffffd5f0, p_second_phase=true) at main/main.cpp:1321
#24 0x0000000001be2f01 in main (argc=1, argv=0x7fffffffd5e8) at platform/x11/godot_x11.cpp:48
Mono seems to be asserting. @neikeq
This bug sounds related: https://github.com/mono/mono/issues/21651
There's a patch available, I'll give it a try.
I've confirmed that the patch from https://github.com/mono/mono/issues/21651 fixes the issue, with this test build of Mono: https://github.com/godotengine/godot-mono-builds/actions/runs/5089774213
I made a minor fix to that test and started a new build which should be available as a GitHub Release in a few hours: https://github.com/godotengine/godot-mono-builds (Same as the artifacts from the above build, just with a cleaner commit history.)
I'll use this build for the next 3.5 and 3.6 builds, possibly fast-tracking a 3.5.3 release to make that fix readily available.
It's a regression in the Linux kernel which should hopefully be patched soon, and thus this Mono workaround wouldn't be needed, but I don't know the ETA for the kernel fix to make it to a stable branch, and whether it will be backported to 6.1, 6.2 and 6.3.
The upstream regression is fixed in kernel 6.1.30 and 6.3.4. 6.2 seems to have gone EOL before this could be backported, so it will stay vulnerable, but most distros should upgrade to 6.3 since 6.2 isn't an EOL.
So this can likely be considered fixed, without me needing to actually use the mono workaround. I'll keep this issue open for now so users can have visibility over this if they're still on a kernel with the regression.
Godot version
3.5.stable, 3.6.beta2
System information
Fedora 38, Fedora 37 (inside podman with unchanged image)
Issue description
Recently I have started to see Godot crash very often when it tries to start on my Linux desktop (Fedora 38, Edit: there was a typo here). This makes debugging and testing a bit difficult but still doable if I try to start Godot many times. So this crash doesn't happen always, just more than half the time. The crashing started likely about 2 weeks ago when I last installed updates.
I was hoping that 3.6 wouldn't have the same problem, but I just tested it and it does also randomly crash when starting. So I'm reporting this issue in the hopes that this could be fixed before 3.6 is fully released.
I suspect that the problem is related to Linux system updates as just today our CI servers started having failed builds. They fail like this:
The Godot process is ran inside podman with the exact same image that worked a few days ago. Also I disabled the build servers that were updated yesterday, and the servers that still haven't had latest updates (last updated a month ago) still build fine. So I'm quite confident in saying that one of the updated packages in the latest round of installed causes this (maybe the kernel as none of the other stuff should really matter when running inside podman):
So in summary it looks like installing latest Linux updates now causes Godot to fail to start very often.
Steps to reproduce
Try to start Godot 3.5 or 3.6 beta 2 on an up to date Fedora system (probably some other distros will soon have new enough packages to have the same problem):
Note that the problem doesn't trigger each time, but for me it triggers often enough for it not to take more than 30 seconds of just continually trying to open Godot to see it crash at least once.
Minimal reproduction project
No project required, the Godot Editor itself can crash when opening.