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 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 ...

@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?