Godot 4 compiled with MinGW is crashing with a white screen [GCC 11.x bug fixed in 11.3] #51070
Comments
|
There's likely the same issue in the 3.3.x builds already include the Thread modernization work, but they're built on Fedora 33 with MinGW 7.0.0 and GCC 10.2.1. The new builds (3.4 beta 1 and beta 2, and https://downloads.tuxfamily.org/godotengine/testing/4.0/4.0-dev.20210727/) are built on Fedora 34 with MinGW 8.0.0 and GCC 10.3.1. |
|
@akien-mga I have just built the |
|
Thanks, these might be separate issues in the end then. Which MinGW versions do you have (both the version of MinGW itself, which should typically be 7.0.0, 8.0.0 or 9.0.0, and the GCC or LLVM version compiled against the MinGW headers)? |
|
I'm using MSYS with MinGW 9.0.0.6246.ae63cde27-1 and GCC 10.3.0. gcc -v |
|
I tested it again to see if it was still relevant. I tried with 0121ce9 and with updated MSYS and MinGW, but the result is exactly same. MinGW: 9.0.0.6346.6cc97775a-1 gcc -v |
|
A few more things I found out: I believe (but cannot prove) that there are compatibility problems with the newer versions of the compiler. OpenSuse gcc -vDebian gcc -v |
|
@MmAaXx500 I can compile Godot's Maybe give llvm-mingw a try? It's still MinGW, but it uses Clang instead of GCC and should provide faster link times. Make sure to add two the installation's |
|
@Calinou Thanks for the suggestion about Clang. I will use it while this gets sorted out.
I can compile it too, but cannot launch. Here is a gif about the issue. I read in the docs that gcc is recommended for release build, that's why I'm trying to get it working. What is your opinion, is it a viable option to use Clang for release builds? |
|
Clang might be a decent option for release builds on Windows too, though I don't have much experience with it (official builds use GCC as provided in Fedora 34 - at least an image from 5 months ago). I'd still be interested to figure out what's the exact component that causes the issue you're experiencing, so we can make sure it won't affect official builds too. |
|
Tried with Fedora 34, it's works as expected, but with Fedora 35 I can reproduce this issue. (so do not update the official build server 😄) Fedora 34 gcc -vFedora 35 gcc -v |
|
I think I found something. F34 uses 8.0.0 and F35 uses 9.0.0 mingw (assuming Just to summarize, here is a table:
(after I wrote the table, I'm not sure about I really found something) |
|
To clarify, Debian Sid's GCC should be 10.2.1 as of the current package https://packages.debian.org/sid/gcc-mingw-w64 (Though GCC versioning in distros is tricky as |
|
Thanks! Corrected it. I wrote "10" because |
|
I tried a local build on Mageia 9 with MinGW 9.0.0 and GCC 11.2.1 (20211019) which should be pretty much the same as Fedora 35's config as Mageia's mingw-gcc packaging is based on Fedora's. It works fine for me when running through Wine on Linux, but I have yet to actually test it on Windows (will do asap). Here's the build if you want to test (note: built with |
|
Your build works for me. I built one on Mageia 8 because they don't have a docker image for 9, and it worked too (except it did not have an icon). gcc -v |
|
That's interesting, then the culprit is likely neither MinGW nor GCC but another component. This could be the (mingw-)binutils version. Fedora 34, Mageia 8 and Mageia 9 have mingw-binutils 2.34, while Fedora 35 and Debian Sid have mingw-binutils 2.37. |
|
MSYS2 have 2.37 |
|
So yeah binutils sounds like a likely culprit. I'll see if I can use Fedora 35's mingw-binutils on Fedora 34 to see if that produces a crashing binary. And then we'd have to try to bisect that with intermediate releases and report the issue upstream, though we'd need to identify a bit more precisely how binutils relates to this (thread-related?) crash. |
|
Can you still reproduce this with binutils 2.38, if MSYS2 provides it? |
|
Yes I can.
I wonder why no one has reported this in the last half year. Am I alone with this issue? |
|
Another test because MinGW 10 was released, but the result has not changed.
I have also updated the table in the first post with the new tests and added the binutils version column. |
|
@akien-mga I have some good news! I found a way* to make it work. (* two ways. See follow-up comment) Compile binutils with reverted Patch here: MmAaXx500/binutils-gdb-godot@b02b583 Below, some of my inexperienced observations:
I'd like to note that I don't have much knowledge in this area, so I cannot determine who is "at fault" or what exactly causing this issue. |
|
Another workaround without modifying binutils. Just pass the base address as a parameter. |
|
Thanks for documenting all this! That's an area with @hpvb is probably the most competent to figure out what we need to do exactly / if we have to report a regression upstream. |
|
With the release of the alpha 8 I noticed that the Windows binaries works, although it was compiled on Fedora 36 which has binutils 2.37. This is not in line with the previous assumptions/findings, so I tested again on various distributions.
I have looked through the patches of MSYS and the only patch could be related is this, but it was released on 2021 Jul 28, so it is included in all of my test with MSYS (therefore not related). Another thing is the whole binutils package haven't been touched since 2022 Mar 1, the build didn't work on 2022 Apr 20, but it magically started working today (I tested it today, so I do not know when precisely). Arch currently have I think this issue is neither binutils' nor gcc's solely fault, rather something of a compatibility issue between them, which seems to be resolving itself as the distributions releasing the newer packages. |
|
So after spending some time chasing the wrong issue in #61176, I finally realized that Mono builds for Godot 3.x seem to be affected by the same issue you describe. Windows binaries built on Fedora 35 are crashing, while Fedora 36 is fine. Thanks a lot for all the debugging you've done so far and documenting your findings. I'm still not sure what we can do to get this actually fixed in the upstream MinGW distributions, but at least we can make sure to use Fedora 36+ / skip Fedora 35 for official builds. Since the bug is fixed in recent toolchains, we can assume that upstream projects did find the regression and got it fixed in the relevant affected projects (but that didn't get backported all the way to past releases). For the record, I did a couple test builds to confirm that I get a crash with Fedora 35 and a working binary with Fedora 36 in the current |
|
For the record, I now think that this issue might have been a GCC regression in 11.2 (maybe 11.1 too), which got fixed in later versions. Because that seems to be the only significant between the mingw-headers, mingw-gcc and mingw-binutils package of Fedora 35 and Fedora 36.
So I suspect this was found and fixed in the 11.x stable branch after 11.2 was released. There was a 11.3 release earlier this year which should also have the fix I suppose. TL;DR: Avoid GCC 11.1 or 11.2, unless it's a snapshot more recent than the July 2021 11.2 release. GCC 11.3 or 12.1+ should be fine. |
akien-mga
changed the title
|
Closing as there isn't much more actionable from our side, aside from having this documented here. We could put a note in the compilation docs or add some checks to prevent building with GCC 11.1 or 11.2, but most distros by now should provide either 11.3, a newer GCC, or still be on an older version. |
Godot version
4.0 custom build (bdcc874)
System information
Windows 10 21H1
Issue description
The editor is crashing with a white screen on startup, with or without a project. I have been tried some combinations of compilers and options:
MSVC with debug -> OK
MSVC with release_debug -> OK
MinGW with debug -> OK
MinGW with release_debug -> Crash
This issue has been introduced with the 99fe462 commit.
Output of drmingw
Log of the crashing MinGW release_debug build
Log of the working MinGW debug build
Summary of tried combinations and result of it:
[1] The icon from the executable was missing
Steps to reproduce
For a not working build:
scons platform=windows target=release_debug use_mingw=yes -j12For a working build:
scons platform=windows target=debug use_mingw=yes -j12Minimal reproduction project
No response
The text was updated successfully, but these errors were encountered: