godot: 3.4beta2 random crashes on Windows during project load (buildsystem regression with GCC 10.3.1)

Godot version

3.4beta2

System information

Windows 10 Pro, 64-bit, 32GB RAM, i9 @ 2.40GHz, NVIDIA Quadro T2000, Intel UHD Graphics

Issue description

Opening a stable 3.3.2 (large) project crashes Godot randomly during load.

The crash occurs during resource (Re)Import (after deleting the .import folder), after it, during resource loading (scripts, scenes, etc) at random times.

The project loads every time when launching the executable from a DOS box with the -v switch, but the output doesn’t provide any significant info. Hence I suspect something related to output buffering.

The project is GLES2.

FWIW it crashes every time in verbose mode too, with alternating sections of normal resouce load with GL ERRORS:

Steps to reproduce

Open a large project on Windows which loaded okay on 3.3.2.

Minimal reproduction project

No response

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 42 (26 by maintainers)

Commits related to this issue

Windows: Fix GCC regression in Fedora 34's mingw-gcc Solves the crash reported in https://github.com/godotengine/godot/issues/50970. — committed to godotengine/build-containers by akien-mga 3 years ago

Most upvoted comments

I think I found the upstream GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402

It was fixed in May but the Fedora packages for Fedora 33 and 34 haven’t been updated yet, I’ll ping the Fedora maintainer. In the meantime I’ll rebuild mingw-gcc with the fix for our containers.

akien-mga on Aug 5, 2021

Great work, I can reproduce the crash on Windows with both MRPs 👍

We should have a fix for 3.4 beta 3 😃

akien-mga on Aug 3, 2021

Here’s the fixed build with LTO: https://downloads.tuxfamily.org/godotengine/testing/Godot_v3.4-beta-d835b46-fixmingw_win64.exe.zip

Using containers built from https://github.com/godotengine/build-containers/pull/92.

akien-mga on Aug 5, 2021

So it can be caused by either of those changes:

A regression in GCC between 10.2.1 and 10.3.1

src.fedoraproject.org/rpms/mingw-gcc/c/a2c54541ee6081e68127884bbec24eaacf30eff3?branch=f34

src.fedoraproject.org/rpms/mingw-gcc/c/13085194a063971b4f4d4c4675cc77bd064a29fd?branch=f34

Tested mingw64-gcc-10.2.1-6.fc34 (last revision before 10.3.1-1.fc34) and it works fine, so it’s indeed a regression between GCC 10.2.1 and 10.3.1.

akien-mga on Aug 5, 2021

Some more findings: #50951 is indeed the same issue (too bad I missed the connection earlier, might have saved some work isolating reproducers here).

The issue happens only when building with Fedora 34’s MinGW and related components so far. I’ve tried a local build on Windows 10 with MinGW from MSYS2 and so far it’s not crashing.

With MSYS2 I have MinGW 9.0.0.6270.0e0eed623 with GCC 10.3.0 and binutils 2.37.

I did manage to get some stacktrace when running the Fedora compiled binary through GDB on Windows (binary compiled without LTO and with debug symbols):

Thread 1 received signal ?, Unknown signal.
0x00007ffe056f2406 in ntdll!RtlRaiseStatus ()
--Type <RET> for more, q to quit, c to continue without paging--
   from /c/Windows/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x00007ffe056f2406 in ntdll!RtlRaiseStatus ()
   from /c/Windows/SYSTEM32/ntdll.dll
#1  0x00007ffe05620bb3 in ntdll!RtlUnwindEx ()
   from /c/Windows/SYSTEM32/ntdll.dll
#2  0x00007ffe04a32eed in msvcrt!_setjmpex ()
   from /c/Windows/System32/msvcrt.dll
#3  0x00000000024a127a in gray_record_cell (worker=0x0,
    worker@entry=0x415db5b0) at thirdparty/freetype/src/smooth/ftgrays.c:545
#4  0x00000000024a220a in gray_set_cell (ey=71, ex=1096660400,
    worker=0x415db5b0) at thirdparty/freetype/src/smooth/ftgrays.c:585
#5  gray_render_scanline (worker=0x415db5b0, ey=71, x1=<optimized out>,
    y1=121, x2=11039, y2=108) at thirdparty/freetype/src/smooth/ftgrays.c:686
#6  0x00000000024a2476 in gray_render_line (worker=worker@entry=0x415db5b0,
    to_x=11039, to_y=18284) at thirdparty/freetype/src/smooth/ftgrays.c:832
#7  0x00000000024a2a5e in gray_render_conic (worker=0x415db5b0,
    to=<optimized out>, control=<optimized out>, to=<optimized out>,
    control=<optimized out>) at thirdparty/freetype/src/smooth/ftgrays.c:1060
#8  0x00000000024a2adf in gray_conic_to (control=<optimized out>,
    to=<optimized out>, worker=<optimized out>)
    at thirdparty/freetype/src/smooth/ftgrays.c:1191
#9  0x0000000002470c65 in FT_Outline_Decompose (outline=0x415db700,
    outline@entry=0x150,
    func_interface=func_interface@entry=0x4794740 <func_interface>,
--Type <RET> for more, q to quit, c to continue without paging--
    user=0x415db5b0, user@entry=0x0)
    at thirdparty/freetype/src/base/ftoutln.c:186
#10 0x00000000024a12cb in gray_convert_glyph_inner (worker=0x0,
    worker@entry=0x415db5b0, continued=continued@entry=0)
    at thirdparty/freetype/src/smooth/ftgrays.c:1644
#11 0x00000000024a14a3 in gray_convert_glyph (worker=worker@entry=0x415db5b0)
    at thirdparty/freetype/src/smooth/ftgrays.c:1723
#12 0x00000000024a182a in gray_raster_render (raster=<optimized out>,
    params=<optimized out>) at thirdparty/freetype/src/smooth/ftgrays.c:1839
#13 0x00000000024a1bb2 in ft_smooth_render (render=0x66f751e0,
    slot=0x415db9e0, mode=FT_RENDER_MODE_NORMAL, origin=<optimized out>)
    at thirdparty/freetype/src/smooth/ftsmooth.c:511
#14 0x000000000247483f in FT_Render_Glyph_Internal (library=0x67040b20,
    slot=slot@entry=0x415db9e0,
    render_mode=render_mode@entry=FT_RENDER_MODE_NORMAL)
    at thirdparty/freetype/src/base/ftobjs.c:4652
#15 0x0000000002478995 in FT_Glyph_To_Bitmap (
    the_glyph=the_glyph@entry=0x415dbb98, render_mode=FT_RENDER_MODE_NORMAL,
    origin=origin@entry=0x0, destroy=destroy@entry=1 '\001')
    at thirdparty/freetype/src/base/ftglyph.c:596
#16 0x0000000001b7855f in DynamicFontAtSize::_make_outline_char (
    this=this@entry=0x67040740, p_char=<optimized out>)
    at scene/resources/dynamic_font.cpp:576
--Type <RET> for more, q to quit, c to continue without paging--
#17 0x0000000001b79fcf in DynamicFontAtSize::_update_char (p_char=71 L'G',
    this=0x67040740) at scene/resources/dynamic_font.cpp:627
#18 DynamicFontAtSize::draw_char (this=0x67040740, p_canvas_item=...,
    p_pos=..., p_char=71 L'G', p_next=111 L'o', p_modulate=...,
    p_fallbacks=..., p_advance_only=false, p_outline=true)
    at scene/resources/dynamic_font.cpp:309
#19 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Other findings:

Only crashes for target=release_debug (at least for the editor, for the template it might also crash in target=release, not tested).
LTO doesn’t seem to be the problem, as a build with scons p=windows tools=yes target=release_debug (i.e. no LTO) crashes too.
Edit: I tested upgrading Fedora 34’s mingw-binutils to Fedora 35’s newer 2.37 version, but it still crashes the same. So it must be another component.

akien-mga on Aug 4, 2021

Thanks. We won’t come to that as I have bisected it and have an MRP.

Crash_Win64.zip

This is related to the font size and should be investigated. Might be a Godot problem after all…

The project has one label with a dynamic font, sized 100px + 4px outline.

Observations:

It crashes with these values: size=100, outline=4. It doesn’t crash if outline is 0 or font size is 16.
It is not related to the font per se.

oeleo1 on Aug 3, 2021

(Writing from mobile) I spend some time yesterday trying to reproduce, and later, finding a github project that crash, and it’s not easy. I try a lot of games (from low to big size) from github, from godot wild jams and aplications like pixelorama and non of that crashes, but trying my test scenes i find a way to crash godot compiled with new containers and not with old containers: passing a kinematicbody2D like argument in a signal and getting this argument in a function like a Node2D. I think i can do a scene with this, but i don’t know if the isolated scene, without the autoloads and the “background” stuff will crash…

Ranoller on Aug 3, 2021