Crash when exporting in headless mode on Linux with Godot 4.2.2.rc2 #89674
Comments
|
I'm unable to reproduce this issue. I tested with 4.2.1.stable.mono.official (b09f793) and 4.2.2.rc2.mono.official (c61a686). To export I've used the command Can you reproduce this on non-mono versions of the editor? Also, your MRP doesn't contain a C# project but Thrive is a C# game, can you confirm that your issue also happens when the project doesn't contain C#? |
|
I can confirm that trying to export that project still crashes for me (well I'm still using the 4.2.2 RC2 version, sorry if I missed a newer RC being available). So it does not require a C# project. I also just confirmed that Here is a Dockerfile which reproduces the issue for me (and hopefully for everyone else as well): FROM fedora:39
RUN dnf install -y --setopt=deltarpm=false unzip wget dotnet-sdk-8.0 fontconfig
ENV GODOT_VERSION "4.2.2-rc2"
RUN wget https://downloads.tuxfamily.org/godotengine/4.2.2/rc2/mono/Godot_v4.2.2-rc2_mono_linux_x86_64.zip \
&& wget https://downloads.tuxfamily.org/godotengine/4.2.2/rc2/mono/Godot_v4.2.2-rc2_mono_export_templates.tpz \
&& mkdir .p ~/.cache \
&& mkdir -p ~/.config/godot \
&& mkdir -p ~/.local/share/godot/export_templates/${GODOT_VERSION}.rc2.mono \
&& unzip Godot_v${GODOT_VERSION}_mono_linux_x86_64.zip \
&& mv Godot_v${GODOT_VERSION}_mono_linux_x86_64 godot_dir \
&& mv godot_dir/* /usr/local/bin/ \
&& ln -s /usr/local/bin/Godot_v${GODOT_VERSION}_mono_linux.x86_64 /usr/local/bin/godot \
&& unzip Godot_v${GODOT_VERSION}_mono_export_templates.tpz \
&& mkdir -p ~/.local/share/godot/export_templates/${GODOT_VERSION}.rc2.mono \
&& mv templates/* ~/.local/share/godot/export_templates/${GODOT_VERSION}.rc2.mono/ \
&& rm -f Godot_v${GODOT_VERSION}_mono_export_templates.tpz Godot_v${GODOT_VERSION}_mono_linux_x86_64.zip \
&& rm -rf templates godot_dir
RUN mkdir /project
ADD export_presets.cfg icon.svg icon.svg.import main.tscn project.godot /project
RUN mkdir /project/build
# This is the export step which ends with a segfault
RUN cd /project && godot --export-release Linux/X11 build/BlankProject --headlessPutting that docker file in the sample project folder and running with podman ends with the following: Here's the updated sample project with the included Dockerfile: BlankProject2.zip |
hhyyrylainen
changed the title
|
See #90431 |
|
Tested using the dockerfile above and podman on Fedora 39. The dockerfile had some typos and installed the templates in the wrong folder, here's a fixed version with fully dehardcoded version numbers: I can reproduce the crash with 4.2.2-rc2 and 4.2.2-rc3. It seems fixed in 4.3-dev5. Would be good to figure out which commit fixed it in 4.3 so it could be cherry-picked for a future 4.2.x release. But otherwise the bug appears to be fixed. |
Well I'll keep it open for now as reminder to try to find that commit. |
|
So I did some more testing, the bug is not reproducible in any 4.3 dev snapshot, nor 4.2-stable, 4.2.1-stable, or 4.2.2-rc1... but it's indeed present in 4.2.2-rc2, so it was a regression all along. It's also still reproducible in 4.2.2-rc3, so that's a release blocker for 4.2.2-stable. I also confirmed that the bug is not specific to the Mono build, it crashes the same with the standard build. Trimmed down Dockerfile for that test: |
|
Here's a backtrace: This points at #87392 likely causing the regression. It works in 4.3, but evidently this wasn't applicable as is to 4.2.x. CC @clayjohn Edit: Confirmed that reverting 5f92e6e fixes it. |
|
Fixed by #90738. |
Tested versions
System information
Fedora 39, also happens inside a podman container with Fedora 39 base with minimal packages
Issue description
When exporting in headless mode I get a crash:
Running without the headless flag works:
(though it prints this error: #84839)
When I export my full project, I get slightly different results, instead of SIGSEGV I get SIGILL:
Steps to reproduce
--headlessflag from terminal, observe it crashesgodot --export-release Linux/X11 build/BlankProject)Minimal reproduction project (MRP)
BlankProject.zip
The text was updated successfully, but these errors were encountered: