godot
godot copied to clipboard
Crash when clicking on "Donors" in About dialog
Godot version
v4.0.rc2.official [d2699dc7a]
System information
Garuda Linux, AMD 6900XT, Kernel 6.1 xanmod
Issue description
Start Godot and Project > Go to Help > About Clicking on Tab "Donors" makes Godot Crash.
Steps to reproduce
Start Godot and Project > Go to Help > About Clicking on Tab "Donors" makes Godot Crash.
Minimal reproduction project
Start Godot and Project > Go to Help > About Clicking on Tab "Donors" makes Godot Crash.
I can't reproduce this with a Windows 10 laptop.
It might have somthing to do with my Project Settings, i made a Backtrace... but i wonder why that would be a problem when clicking on the Donors Tab.... Here the Backtrace:
❯ Vulkan API 1.3.230 - Forward+ - Using Vulkan Device #0: AMD - AMD Radeon RX 6900 XT (RADV NAVI21) ⇣22.67 KiB/s ⇡2.81 KiB/s 192.168.78.10
WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
at: _editor_init (modules/gltf/register_types.cpp:70)
ERROR: FATAL: Index p_index = 215 is out of bounds (size() = 215).
at: get (./core/templates/cowdata.h:155)
================================================================
handle_crash: Program crashed with signal 4
Engine version: Godot Engine v4.0.rc2.official (d2699dc7ab96fbd75faccc1f32f55baebf1d84dc)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x38f50) [0x7f87bbb92f50] (??:0)
[2] /usr/bin/godot4() [0x2ce2687] (??:0)
[3] /usr/bin/godot4() [0x4528e64] (??:0)
[4] /usr/bin/godot4() [0x2aa11d6] (??:0)
[5] /usr/bin/godot4() [0x4b42785] (??:0)
[6] /usr/bin/godot4() [0x4599f67] (??:0)
[7] /usr/bin/godot4() [0x2bb0b05] (??:0)
[8] /usr/bin/godot4() [0xeb88bb] (??:0)
[9] /usr/bin/godot4() [0xdf5603] (??:0)
[10] /usr/lib/libc.so.6(+0x23790) [0x7f87bbb7d790] (??:0)
[11] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f87bbb7d84a] (??:0)
[12] /usr/bin/godot4() [0xe156ee] (??:0)
Unfortunately, that trace is obfuscated. If you can compile Godot yourself, with debug symbols, then we can have a useful stack trace.
Compile the most recent git Source, heres the stack trace:
handle_crash: Program crashed with signal 4
Engine version: Godot Engine v4.0.rc.custom_build (f2aae8fa5c2e9d9323832fb43c8446c2e518d698)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x38f50) [0x7f6a6e6bdf50] (??:0)
[2] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x2ebda27) [0x55d7e2c0ca27] (??:0)
[3] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x4c0c724) [0x55d7e495b724] (??:0)
[4] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x2c6a617) [0x55d7e29b9617] (??:0)
[5] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x4c08679) [0x55d7e4957679] (??:0)
[6] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x4c089bc) [0x55d7e49579bc] (??:0)
[7] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x2d075f0) [0x55d7e2a565f0] (??:0)
[8] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0xb45445) [0x55d7e0894445] (??:0)
[9] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0xadbd71) [0x55d7e082ad71] (??:0)
[10] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0xacdd09) [0x55d7e081cd09] (??:0)
[11] /usr/lib/libc.so.6(+0x23790) [0x7f6a6e6a8790] (??:0)
[12] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7f6a6e6a884a] (??:0)
[13] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0xad9f05) [0x55d7e0828f05] (??:0)
-- END OF BACKTRACE --
You need to compile explicitly with debug_symbols=yes (or dev_build=yes which implies it, but note that it will change the name of the binary to godot.linuxbsd.editor.dev.x86_64).
I can't reproduce the issue on Mageia 9 Linux, running KDE Plasma / KWin on X11.
I suspect it's a window manager related issue, which one are you running, and is it on X11 or Wayland?
I'm unable to reproduce this on Debian Linux X11 Xfce.
Thanks for the guidance, here's the backtrace with the "debug_symbols=yes" switch:
handle_crash: Program crashed with signal 4
Engine version: Godot Engine v4.0.rc.custom_build (f2aae8fa5c2e9d9323832fb43c8446c2e518d698)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x38f50) [0x7fb1389cbf50] (??:0)
[2] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x2ebda27) [0x55ed998d6a27] (/opt/godot/./core/templates/cowdata.h:155)
[3] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x4c0c724) [0x55ed9b625724] (/opt/godot/core/object/object.cpp:792)
[4] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x2c6a617) [0x55ed99683617] (/opt/godot/scene/main/canvas_item.cpp:136)
[5] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x4c08679) [0x55ed9b621679] (/opt/godot/core/object/message_queue.cpp:230)
[6] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x4c089bc) [0x55ed9b6219bc] (/opt/godot/core/object/message_queue.cpp:277)
[7] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0x2d075f0) [0x55ed997205f0] (/opt/godot/scene/main/scene_tree.cpp:463)
[8] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0xb45445) [0x55ed9755e445] (/opt/godot/main/main.cpp:3162)
[9] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0xadbd71) [0x55ed974f4d71] (/opt/godot/platform/linuxbsd/os_linuxbsd.cpp:880)
[10] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0xacdd09) [0x55ed974e6d09] (/opt/godot/platform/linuxbsd/godot_linuxbsd.cpp:75)
[11] /usr/lib/libc.so.6(+0x23790) [0x7fb1389b6790] (??:0)
[12] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7fb1389b684a] (??:0)
[13] /opt/godot/bin/godot.linuxbsd.editor.x86_64(+0xad9f05) [0x55ed974f2f05] (??:?)
-- END OF BACKTRACE --
Hope thats better ?
Yes, it's a bit better, but it seems we won't see the cause in the backtrace. Could you answer this question to give us more details for a reproduction?
I suspect it's a window manager related issue, which one are you running, and is it on X11 or Wayland?
I am on x11. Tried it with different kernels also...
❯ xdpyinfo | grep -A4 '^screen'
screen #0:
dimensions: 3840x1600 pixels (855x356 millimeters)
resolution: 114x114 dots per inch
depths (7): 24, 1, 4, 8, 15, 16, 32
root window id: 0x6b8
❯ echo $XDG_SESSION_TYPE
x11
❯ plasmashell -v
plasmashell 5.26.5
❯ glxinfo | grep -iE 'vendor:|device:|version:'
GLX version: 1.4
Vendor: AMD (0x1002)
Device: AMD Radeon RX 6900 XT (navi21, LLVM 15.0.7, DRM 3.42, 5.15.93-1-lts) (0x73bf)
Version: 22.3.4
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
❯ uname -r
5.15.93-1-lts
PS: also tested with a Wayland Session, same result (crash).
PPS: i can confirm that i do not have this Crash on my laptop, same system (Garuda) in same versions, but no AMD graphics but intel iris xe. So that may be something specific to my hardware config... also have an nvidia GPU inside for GPU passthrough for my VMs. That might contribute to that crash? Anyway, if noone else has this bug it might be closed?
Yes, it's a bit better, but it seems we won't see the cause in the backtrace. Could you answer this question to give us more details for a reproduction?
I suspect it's a window manager related issue, which one are you running, and is it on X11 or Wayland?
I had the same or similar crash in v4.0.stable.official [92bee43ad]
I've got this backtrace in a custom build from 1c1524a651e6d670d0d591b050d8c4bbb721d6e9
ERROR: FATAL: Index p_index = 214 is out of bounds (size() = 214).
at: get (./core/templates/cowdata.h:155)
================================================================
handle_crash: Program crashed with signal 4
Engine version: Godot Engine v4.1.dev.custom_build (1c1524a651e6d670d0d591b050d8c4bbb721d6e9)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x38f50) [0x7ffff7a51f50] (??:0)
[2] CowData<ItemList::Item>::get(int) const (/home/mrcdk/development/godot/godot/./core/templates/cowdata.h:155)
[3] Vector<ItemList::Item>::operator[](int) const (/home/mrcdk/development/godot/godot/./core/templates/vector.h:93)
[4] ItemList::_notification(int) (/home/mrcdk/development/godot/godot/scene/gui/item_list.cpp:1211)
[5] ItemList::_notificationv(int, bool) (/home/mrcdk/development/godot/godot/scene/gui/item_list.h:39)
[6] Object::notification(int, bool) (/home/mrcdk/development/godot/godot/core/object/object.cpp:790)
[7] CanvasItem::_redraw_callback() (/home/mrcdk/development/godot/godot/scene/main/canvas_item.cpp:136)
[8] void call_with_variant_args_helper<CanvasItem>(CanvasItem*, void (CanvasItem::*)(), Variant const**, Callable::CallError&, IndexSequence<>) (/home/mrcdk/development/godot/godot/./core/variant/binder_common.h:298)
[9] void call_with_variant_args<CanvasItem>(CanvasItem*, void (CanvasItem::*)(), Variant const**, int, Callable::CallError&) (/home/mrcdk/development/godot/godot/./core/variant/binder_common.h:408)
[10] CallableCustomMethodPointer<CanvasItem>::call(Variant const**, int, Variant&, Callable::CallError&) const (/home/mrcdk/development/godot/godot/./core/object/callable_method_pointer.h:?)
[11] Callable::callp(Variant const**, int, Variant&, Callable::CallError&) const (/home/mrcdk/development/godot/godot/core/variant/callable.cpp:51)
[12] MessageQueue::_call_function(Callable const&, Variant const*, int, bool) (/home/mrcdk/development/godot/godot/core/object/message_queue.cpp:229)
[13] MessageQueue::flush() (/home/mrcdk/development/godot/godot/core/object/message_queue.cpp:277)
[14] SceneTree::physics_process(double) (/home/mrcdk/development/godot/godot/scene/main/scene_tree.cpp:430)
[15] Main::iteration() (/home/mrcdk/development/godot/godot/main/main.cpp:3123)
[16] OS_LinuxBSD::run() (/home/mrcdk/development/godot/godot/platform/linuxbsd/os_linuxbsd.cpp:880)
[17] /home/mrcdk/development/godot/godot/bin/godot.linuxbsd.editor.dev.x86_64.llvm(main+0x22b) [0x55555a1f94ab] (/home/mrcdk/development/godot/godot/platform/linuxbsd/godot_linuxbsd.cpp:73)
[18] /usr/lib/libc.so.6(+0x23790) [0x7ffff7a3c790] (??:0)
[19] /usr/lib/libc.so.6(__libc_start_main+0x8a) [0x7ffff7a3c84a] (??:0)
[20] /home/mrcdk/development/godot/godot/bin/godot.linuxbsd.editor.dev.x86_64.llvm(_start+0x25) [0x55555a1f91a5] (??:?)
-- END OF BACKTRACE --
================================================================
My system:
Operating System: Manjaro Linux
KDE Plasma Version: 5.26.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.12-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 9 5900HX with Radeon Graphics
Memory: 15,1 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Graphics Processor: NVIDIA GeForce RTX 3060 Mobile / Max-Q
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: ROG Strix G713QM_G713QM
System Version: 1.0
I'm getting the same crash in v4.0.stable.official [92bee43ad]. Note that this also happens clicking the Donors tab in the About screen in Project Manager, so shouldn't be related to any project settings.
Operating System: openSUSE Tumbleweed 20230302 KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.2.1-1-default (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-7200U CPU @ 2.50GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 620 Manufacturer: HP Product Name: HP ProBook 450 G4
While I still can't reproduce it, I do see a problem with the code where the stacktrace points. So thanks for that!
It seems that to trigger the crash a certain set of conditions affecting the size of the ItemList needs to be true. It can be related to the system and editor scale settings, font size, or even imprecision from resizing the About dialog itself. So it's likely not related to the OS being used, at least not directly, but the issue would appear to be consistent for a specific machine (so the same user will constantly see it, if none of the conditions change).
I've been debugging a bit and it seems that the items.rect_cache is bad. In this block https://github.com/godotengine/godot/blob/d3415ae5aa18e124f65161881ec45e9930e79d36/scene/gui/item_list.cpp#L1201-L1209 the if(rcache...) condition is true and keeps changing lo to mid + 1 which ends reaching the same value as hi and crashes when trying to get items[lo].rect_cache as lo is the same value as items.size() here https://github.com/godotengine/godot/blob/d3415ae5aa18e124f65161881ec45e9930e79d36/scene/gui/item_list.cpp#L1211-L1213
In the case of the Donors tab items.size() is 214 on my end. This is the rect_cache values from items[213]

in the while(lo < hi) loop when comparing it if (rcache.position.y + rcache.size.y < clip.position.y) the total ends being -2147482368 which is way lower than clip.position.y (-4 in my case)
These are the items[mid].rect_cache where rcache.position.y + rcache.size.y is lower than clip.position.y and change the lo to lo = mid + 1;:
mid value
107 -2147482368
161 -2147482368
188 -2147482368
201 -2147482368
208 -2147482368
211 -2147482368
213 -2147482368
The issue seems to be triggered by the gold donor list as it has 214 names but I have no idea why.
(this has been debugged on a custom build from master v4.1.dev.custom_build [9b9bb418c])
@mrcdk I think the values being incorrect is a temporary fluke that resolves itself. But the case of lo reaching hi is possible logically, so it should be handled (which is what I did in my PR). Checks that it now works correctly are welcome, but at least it should not crash.
Thanks!
I tested the PR locally and the crash doesn't happen anymore but, sadly, the root cause of the issue is still there as the Gold Donors list is empty:

EDIT: Probably the cause of the issue: https://github.com/godotengine/godot/blob/d3415ae5aa18e124f65161881ec45e9930e79d36/DONORS.md?plain=1#L148-L149 It gets into the code when generating the donors header as: \342\220\243 which seems to be correct https://www.cogsci.ed.ac.uk/~richard/utf-8.cgi?input=342+220+243&mode=obytes but it corrupts max_h here https://github.com/godotengine/godot/blob/6ee028d43e2df70c7ede1261127be098471dff5a/scene/gui/item_list.cpp#L1402 making it be -2147483648 because items[44].rect_cache.size.y is NaN
Hmm, interesting. Given the related issue that tried to use some Hebrew characters it implies that we return NaN for some characters we can't parse when some specific fonts are involved.
The rect_size there is based on the height fetched from this line: Size2 s = items[i].text_buf->get_size();. Which is a TextParagraph method (and that in turn uses TS->shaped_text_get_size). Nothing else should be able to return NaN in that equation. Perhaps this is where we should add an is_nan check?
CC @bruvzg
It definitely should never return NaN, without font it can be 0, but not NaN. So it's either broken font which have nonsensical ascent/descent, or NaN was passed to the shaped_text_set_spacing.
I wouldn't rule out a nonsensical font, especially if it's some old system font 🙃 The question is, how do we guard against it? I can check for NaN in ItemList, but there are many other users of these TS methods.
It's likely non TTF/OTF format font which is supported by freetype, so it is loaded but do not have enough metadata, I'm not sure if we can do check for it (at least without font sample to test). But I guess text server can check for the font ascent/descent and glyph sizes to be at least positive or zero.
Yep, looks like the glyph is broken:

Because gl.y_off is NaN it ends setting the ascent and descent to NaN here https://github.com/godotengine/godot/blob/c1128e911ccd6f1e8c35646df804d894652a58f1/modules/text_server_adv/text_server_adv.cpp#L4197-L4198
And, yep, it looks like the font it's using for that glyph isn't a TTF or OTF font:

I think this is the one as the file fonts.alias has this line:
fixed -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1
where the fonts.dir points to:
6x13-ISO8859-1.pcf.gz -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1

I've uploaded the misc folder here. misc.zip
I'm just guessing that's the font it's trying to use because that's one of the fonts that appears when I search fixed in the font management system settings.

I've uploaded the misc folder here. misc.zip
As I suspected : ascent/descent == 0, ppm scale == 0 so scaling end up inf and mess up glyph sizes as well.
Just a quick reply from my side.
Build a view minutes ago from source. works also on my machine now :)
Thanks!
