All my work on Liblast is halted due to a blocking freeze bug.

I have a live presentation and workshop coming up in 4 weeks that depends on this tech, and I can't do anything at the moment.

In case you're familiar with Godot's C++ side or debugging C++ software in general, maybe you can help me out of this ditch?
Help!

https://github.com/godotengine/godot/issues/117712

Spreading the word is often a great help as well!

#Liblast #Help #Godot #GodotEngine

Freeze on Game Start · Issue #117712 · godotengine/godot

Tested versions Reproducible in 4.6.1 stable Reproducible in 4.7-dev2 Reproducible in git main (v4.7.dev.custom_build.65e73b3a5) System information Arch Linux, KDE, Wayland, Godot 4.6.1 stable - 4....

GitHub

@unfa I'm not having the lockup issue. I am getting 28 errors on import when following your instructions but I get the below screen, and these lines on the console beyond where you lock up:

· IntroSequence: start
WARNING: 2D MSAA is enabled while there is no 2D content. Disable 2D MSAA for better performance.
at: _draw_viewport (servers/rendering/renderer_viewport.cpp:725)
[·] CVarTree: saving a read-only tree "base" to file. This is only useful for debugging.
[✓] CVarTree "base": saved to file OK
[·] IntroSequence: finished animation (intro)
[·] intro sequence finished...
ERROR: Path to node is invalid: 'Display/SubViewport'.
at: _setup_local_to_scene (scene/main/viewport.cpp:199)
GDScript backtrace (most recent call first):
[0] spawn_gui (res://addons/liblast_framework/core/core.gd:259)
[1] _init (res://addons/liblast_framework/core/core.gd:188)
[2] spawn_intro_sequence (res://addons/liblast_framework/core/core.gd:228)
[3] finish (res://addons/liblast_framework/gui/intro_sequence/intro_sequence.gd:28)
ERROR: Path to node is invalid: 'Display2/SubViewport'.
at: _setup_local_to_scene (scene/main/viewport.cpp:199)
GDScript backtrace (most recent call first):
[0] spawn_gui (res://addons/liblast_framework/core/core.gd:259)
[1] _init (res://addons/liblast_framework/core/core.gd:188)
[2] spawn_intro_sequence (res://addons/liblast_framework/core/core.gd:228)
[3] finish (res://addons/liblast_framework/gui/intro_sequence/intro_sequence.gd:28)
· CharacterSetupMenu found character body material: (res://addons/liblast_framework/data/materials/extended_materials/character_greg.tres):<ShaderMaterial#-9223371972950358403>
[·] CharacterSetupMenu found customizable color parameters: 4

This is on Linux Mint 21.3, XFCE, X11, Godot 4.6.1 .NET, AMD Radeon RX 6700.

1/2

@unfa Closing the game causes the below to appear:
WARNING: 1 RID of type "CanvasItem" was leaked.
at: _free_rids (servers/rendering/renderer_canvas_cull.cpp:2690)
ERROR: 1 RID allocations of type 'N10RendererRD14TextureStorage7TextureE' were leaked at exit.
WARNING: 9 RIDs of type "Texture" were leaked.
at: finalize (servers/rendering/rendering_device.cpp:7505)

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.6.1.stable.mono.official (14d19694e0c88a3f9e82d899a0400f27a24c176e)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues
Segmentation fault (core dumped)

godotengine/godot

Godot Engine – Multi-platform 2D and 3D game engine - godotengine/godot

GitHub
@trebach Heh. Glad it works on your end! I am starting to think this is Arch Linux-specific. These errors are expected, nothing surprising to me.

@unfa you'll want to look at stack traces of all threads when something is hanging like that. gdb has the handy taas bt to get every thread's backtrace in just one command.

you'd probably want to see if letting the program continue for a moment lets any of the threads "do something" or if they are all waiting for something, and so on ...

@unfa does it only happen with wayland, not with X11? I can't reproduce freeze on my machine: fedora kinoite, kde plasma X11, Vulkan 1.4.328 - Forward+ - Using Device #0: AMD - AMD Radeon RX 9070 XT (RADV GFX1201)
@timotimo I need to install X11, as it seems to be missing from my systems and try, thanks!
@unfa @timotimo You can force X11 for an app through the command line even on Wayland. Since X11 applications run through Xwayland, that is sufficient for verifying the difference.

If I understand correctly, and I'm not 100% sure how to verify, godot will default to X11 if you don't go to project settings -> (advanced settings) -> display server and change the linuxsbd entry to wayland, it looks like at least in the project inside the git repo it's not set to wayland, or maybe that's something you have to do after "reimporting"?

it's quite possible the game was already running through XWayland when unfa was testing

@timotimo I'd rather not guess. Opening a terminal and unsetting `WAYLAND_DISPLAY` is enough to force an application to use X11.
@neal @timotimo Thanks. I made the game print out what display manager is used and it shows X11 every time ecen when I try to use Wayland, and despite my whole DE running on Wayland. I am not sure I can force Wayland on Godot at this point, or is the information from DisplayServer wrong.
@timotimo I have posted backtrace in the linked GitHub issue, but it's only for main thread, I'll try multiple threads too...
@unfa yes, looking at all threads will be crucial; when you stop the program with SIGSTOP like when you ctrl-c it inside the gdb console, you get more or less a random thread
@unfa looking at the offending commit you found, I'm wondering if it's a problem that you're outputting to Log when clearing the log text field. I can't tell from just that folder if the log that Log.log outputs to is also in the log_sources array?
is it possible that get_line_count doesn't update immediately when clear_contents is called? then it might be infinitely looping trying to clear over and over? or for some reason something is outputting a really really long output that itself has a thousand lines in it?
@unfa this may/may not be helpful, but I started getting random hangs after I switched from PopOS with x11 Plasma to Kubuntu with Wayland Plasma. It didn't happen all the time and I could get past it by running in a scene that wasn't my start scene (iirc running normally after this wouldn't hang).

@unfa I see from the GH comments that you're seeing the same behaviour even with older commits and Godot versions, which makes me suspect it's an interaction with a system library that got updated recently.

So it might be worth checking out your systems' update logs, to see what packages got updated around the time it started happening?

@ambimist That's what aim suspecting, but I don't know yet how to do that. Maybe I'll try booting from a Timeshift snapshot to test older version of the whole OS... It does seem to be unrelated to Godot and project version.
@unfa I have Arch, x11, RTX3050Ti, cloned 4.6.1 compiled, ran following your steps, it runs fine. I see some validation errors related to relaxed precision (midp/min16float) though, but that should not cause any deadlocks.
@alariq Thank you, so far it seems like a Wayland update might be at fault here. I will try X11.