Godot: Editor/script editor random freezing on Linux

[maksloboda]

Godot version: 3.1 stable

OS/device including version: Ubuntu 18.04 LTS 64bit

Issue description:

Script editor randomly freezes the whole editor, but pressing Alt key fixes it

Steps to reproduce:
It always happened when scrolling script using the mouse wheel
click dragging on the right doesnt trigger it
pressing alt fixes it immediately pressing win key also helps

[Calinou]

Does this occur if you disable Text Editor → Open Scripts → Smooth Scrolling in the Editor Settings?

[maksloboda]

@Calinou freezing is gone

[bojidar-bg]

Potentially a remnant of #23314.

[Overblob]

I still get this issue with Smooth Scrolling disabled

[maksloboda]

After a day of use it froze once

[Overblob]

I got it a lot more (at least twice an hour), so...quiet annoying
Actually this isn't a total freeze since inputs seem to be normally processed, however I see the resulting actions only when I "defreeze" the screen with "alt" ("ctrl" and "f11" also work).
So only the rendering seems to be affected.

I'm also using Godot 3.1 stable with Ubuntu 18.04 LTS 64 bits

[maksloboda]

Possibly related is that sometimes after scrolling when trying to select something with a mouse it selects on a wrong line

[Overblob]

Update: This not related specifically to Script Editor, I also got the freeze using the shader editor (possibly while scrolling) but also several times with color pickers in the inspector, after having picked a color

[akien-mga]

If one of you can build from source, you could try to set
https://github.com/godotengine/godot/blob/03581e49b7a31a7bcd4a3ace3a0130ab74afe1cb/editor/editor_node.cpp#L4908
to false, and see if that fixes it.

[maksloboda]

With smooth scroll enabled it still freezes

[maksloboda]

Some times it happens when just typing

[CJNA]

@akien-mga Setting that variable resolved the issue for Linux 18.04 LTS 64 bit version. I will issue pull request soon.

[akien-mga]

@CJNA That's not the proper fix though, it was just to identify what features causes the bug. Disabling the feature doesn't fix the bug, it only hides it (while reintroducing other issues).

[pasimako]

I get this issue on 3.1.1 (Ubuntu 18.04) quite often, and indeed Alt works, but I have also encountered the issue twice while running my game from the editor (Alt unfreezes the screen there, too).

[shoaib-xo]

No fix yet?

[bojidar-bg]

No, we are not sure what causes the issue yet (apart that it is related to the Alt key, scrolling, and maybe dragging). If you can reproduce the issue, determining the exact order of steps you do prior to freezing the script editor would be helpful.

[shoaib-xo]

No, we are not sure what causes the issue yet (apart that it is related to the Alt key, scrolling, and maybe dragging). If you can reproduce the issue, determining the exact order of steps you do prior to freezing the script editor would be helpful.

I will. For now, I have observed that this issue is linked to another weirdness. Say I typed "Edit" and it froze. After, I press Alt, sometimes the chars are received out of order, for exampe "etid," or "ited". This is very weird as I cannot theorize what could cause the keys to go out of order. I would expect the freeze to at least maintain order or input.

[capnm]

This is really annoying "feature". I have to press the Alt-key every ~ 5-10 minutes. It looks as if there is a deadlock between receiving keys from an internal buffer and the (in most cases only annoying) code parsing and code completion threads.

It would be great, as I asked a few years ago, to optionally * disable this automatism * and trigger it only with a shortcut. Most "smart" editors have a configuration option for it.

[Zireael07]

I don't think it's related to scrolling itself, I had the issue too, in both script and shader editor and I wasn't doing any scrolling, just typing text. For shader, the shader was large, but the script was not (200 lines or so)
My suspicion is that something's not playing ball with Ubuntu's compositor in GNOME.

[Calinou]

@capnm @Zireael07 If you're using Linux, does this happen if you set your window manager's "handling" modifier to Super instead of Alt? (This means you'd move windows by using Super + Left Mouse Button instead of Alt + Left Mouse Button, for instance.)

[capnm]

does this happen if you set your window manager's "handling" modifier to Super instead of Alt?

Yes. I have to switch the wm shortcut-handling to Super+* otherwise is e.g. Blender, Krita, ... unusable.

This means you'd move windows by using Super + Left Mouse Button

This bug happens independently, I don't use the Super-key gnome shortcuts at all.

Note: Unfortunately, I had to rollback my Godot classes at school to v2.1.6 : - /
The editor under Linux (within the VMware workstation) was hellishly slow (although the generated 2D apps were acceptable) and this issue was much worse. The kids had to wait about a minute for every tenth keystroke to be displayed on the screen.

[lukaskotik]

It happen to me quite often (about every 5 minutes). Ubuntu 18.04.3, kernell 5.0.0-36, NVidia 1060, driver 430.50. It is very annoying (Thanks for tip with pressing ALT key!). I have handling modifier set to to super. Until now I was not able to identify any consistency in this behaviour, it looks like random events.

[volzhs]

Linux Mint 19.2, 1070 ti with 440.26 driver
I'm also having a problem, quite often and randomly.
using Alt or clicking somewhere in the editor unfreezing it.

[volzhs]

I'm feeling this is very similar with #28704
I have editor freezing randomly while editing node name on scene panel, saving scene or editing script, etc...
and the editor is becoming responsive again by clicking somewhere in the editor.

using 3.2 8ea909f5b6

[Zireael07]

Yeah, most likely one of those issues is a dupe of the other.

[lukaskotik]

I have spent few hours working with Godot at weekend and it really happen very often to me (about each 1 - 3 minutes). For a while I suspect the tool being responsible for that (since I worked mainly with tool scripts) but it also happen in non tool scripts and as volzhs wrote, it also happen to me while editing a node etc.

[volzhs]

here's my experience of freezing.
when disabling Project settings > Debug > Gdscript > Enable, number of freezing is significantly reduced, but still happens rarely.
when editor is frozen, it became alive again when focusing another window, like clicking chrome browser window.

all of alt key, clicking somewhere, changing focus window makes un-freeze editor again, which means it became alive when events happen.

[Zireael07]

What is "degud" supposed to be? :confused:

[volzhs]

What is "degud" supposed to be?

Debug... typo... fixed...

[capnm]

In #29521 is a recipe how to freeze the editor for his remaining life span.
I don't know the Godot internals, but it looks like it's looping between creating and eating up some UI events :no_good_man:

You could try to attach a debugger with sudo gdb <editor process nr>.

[akien-mga]

Can anyone who reproduces the issue try to do it through gdb?
Once the editor freezes, use Ctrl+C in the gdb console to interrupt, and run bt to get a backtrace of where the editor is currently stuck at.

Note that #34770 was just merged and fixes one cause of editor freeze - it doesn't strike me as clearly related to this one, but it might be worth checking in the latest master branch if the bug is still reproducible.

[Zireael07]

I no longer have my Linux box (the SSD failed). Before it failed, the issue seemingly went away when I switched to Kubuntu (so KDE instead of GNOME as the desktop environment).
It further reinforces my suspicions that this is not on Godot's end, but on the DE/gfx card end (all the reporters are using Ubuntu or Linux Mint, which is also GNOME-based under the hood - Cinnamon/Mint is a GNOME derivative)

[maksloboda]

So i tested the master and the old version for a bit. I found that if i violently scroll the script editor or shader editor, then godot would lock up and stop scrolling randomly, and then it would unfreeze after a few redraws, carot of the script editor forces the redraw when it flashes, also unfocusing the editor sometimes does, so i tried to carefully stop the master branch version while it was locked up and got this:

#0  0x00007f1f0a296bf9 in __GI___poll (fds=0x7ffd39ba51a8, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007f1f09b4d747 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007f1f09b4f36a in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007f1f0c4093e8 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007f1f0c3f09f4 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6#5  0x00007f1f0c4386df in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007f1f0c4393e3 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007f1f0c4396e1 in _XimRead () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007f1f0c428a65 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x00007f1f0c416839 in XSetICValues () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#10 0x00000000012f9c48 in OS_X11::set_ime_position (this=0x7ffd39ba7ed0, p_pos=...) at platform/x11/os_x11.cpp:741
#11 0x00000000012f9b7d in OS_X11::set_ime_active (this=0x7ffd39ba7ed0, p_active=true) at platform/x11/os_x11.cpp:724
#12 0x0000000002a00dee in TextEdit::_notification (this=0xad1e510, p_what=43) at scene/gui/text_edit.cpp:1436
#13 0x0000000002a22dd4 in TextEdit::_notificationv (this=0xad1e510, p_notification=43, p_reversed=false) at scene/gui/text_edit.h:43
#14 0x000000000354c07c in Object::notification (this=0xad1e510, p_notification=43, p_reversed=false) at core/object.cpp:952
#15 0x0000000002a04805 in TextEdit::_gui_input (this=0xad1e510, p_gui_input=...) at scene/gui/text_edit.cpp:1965
#16 0x0000000001569de4 in MethodBind1<Ref<InputEvent> const&>::call (this=0x62a7130, p_object=0xad1e510, p_args=0x7ffd39ba7180, p_arg_count=1, r_error=...) at ./core/method_bind.gen.inc:729
#17 0x000000000354b277 in Object::call_multilevel (this=0xad1e510, p_method=..., p_args=0x7ffd39ba7180, p_argcount=1) at core/object.cpp:777
#18 0x000000000354bad8 in Object::call_multilevel (this=0xad1e510, p_name=..., p_arg1=..., p_arg2=..., p_arg3=..., p_arg4=..., p_arg5=...) at core/object.cpp:882
#19 0x000000000285fa85 in Viewport::_gui_call_input (this=0x681ff40, p_control=0xad1e510, p_input=...) at scene/main/viewport.cpp:1537
#20 0x0000000002861279 in Viewport::_gui_input_event (this=0x681ff40, p_event=...) at scene/main/viewport.cpp:1909
#21 0x000000000286569d in Viewport::input (this=0x681ff40, p_event=...) at scene/main/viewport.cpp:2688
#22 0x000000000285e885 in Viewport::_vp_input (this=0x681ff40, p_ev=...) at scene/main/viewport.cpp:1314
#23 0x0000000001569de4 in MethodBind1<Ref<InputEvent> const&>::call (this=0x61fe470, p_object=0x681ff40, p_args=0x7ffd39ba7760, p_arg_count=1, r_error=...) at ./core/method_bind.gen.inc:729
#24 0x000000000354bf03 in Object::call (this=0x681ff40, p_method=..., p_args=0x7ffd39ba7760, p_argcount=1, r_error=...) at core/object.cpp:942
#25 0x000000000354ba04 in Object::call (this=0x681ff40, p_name=..., p_arg1=..., p_arg2=..., p_arg3=..., p_arg4=..., p_arg5=...) at core/object.cpp:866
#26 0x0000000002831f79 in SceneTree::call_group_flags (this=0x6820a60, p_call_flags=2, p_group=..., p_function=..., p_arg1=..., p_arg2=..., p_arg3=..., p_arg4=..., p_arg5=...) at scene/main/scene_tree.cpp:262
#27 0x0000000002832d22 in SceneTree::input_event (this=0x6820a60, p_event=...) at scene/main/scene_tree.cpp:418
#28 0x000000000131316f in InputDefault::_parse_input_event_impl (this=0x5cd6f20, p_event=..., p_is_emulated=false) at main/input_default.cpp:442
#29 0x0000000001312162 in InputDefault::parse_input_event (this=0x5cd6f20, p_event=...) at main/input_default.cpp:259
#30 0x0000000001314470 in InputDefault::flush_accumulated_events (this=0x5cd6f20) at main/input_default.cpp:679
#31 0x0000000001300974 in OS_X11::process_xevents (this=0x7ffd39ba7ed0) at platform/x11/os_x11.cpp:2461
#32 0x0000000001303b29 in OS_X11::run (this=0x7ffd39ba7ed0) at platform/x11/os_x11.cpp:3002
#33 0x00000000012f4a63 in main (argc=4, argv=0x7ffd39ba8648) at platform/x11/godot_x11.cpp:55

Edit: entry #0 was invisible.

[akien-mga]

Nice work! CC @bruvzg who might be familiar with the OS::set_ime_position code.

[bruvzg]

set_ime_position send global coordinates of the focused control cursor to the OS input engine (to display suggestion pop-up window).

It's called on focus changes and on each redraw of the focused control, during the scroll it might be called too often and overflow X11 event query.

[aaronfranke]

Another workaround is to press Ctrl+S, so strangely, implementing https://github.com/godotengine/godot-proposals/issues/940 would probably mask this problem.

[mirceaciu]

I am following this youtube tutorial step by step so nothing complicated is happening in Gotod. I only have chrome browser opened with the youtube tab and a few other pages (git and a mail client).

I am working 8h+ a day on my machine, no freezes. Once a day for 1h I do some Godot stuff and as soon as I open the editor the freezes start. From time to time I am rendering the game and closing it and the freeze will happen (most often) when I change focus between Chrome to Godot.

During a freeze Youtube audio shudders and the buffering/loading animation is overlayed over the video. Godot also is frozen, all UI element are unresponsive. Some of the time the entire OS becomes unresponsive. This lasts for 1-10s. No particular warnings in sys logs

I am running Linux P5RO-PORT859 5.3.0-45-generic #37~18.04.1-Ubuntu SMP Fri Mar 27 15:58:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux and Godot_v3.2.1-stable_x11.64.

I had audio shudders from chrome audio when I was using DAW (digital audio workstations) and those don't seem to like sharing the audio driver, could Godot also have some of those troubles?

[ripperdave]

I experience the temporary freeze too:
Godot 3.2.1 stable 64 bit.
Ubuntu 18.04.4 LTS 64 bit
Intel® Core™ i5-2500K CPU @ 3.30GHz × 4
GeForce GTX 1050/PCIe/SSE2
Gnome 3.28.2

[kinqsley]

current workaround is to press ALT key to unfreeze

[mirceaciu]

no key press workaround works for be but after an update&upgrade of my Ubuntu OS freezes seem less frequent.. hard to measure

[agameraaron]

Hope I'm relevant. My editor only started locking up recently, but may be related to me resizing the partition or running out of space before that...? I use Godot regularly and that's what changed for me. I'm clueless what else could be causing this.

I get random freezes and the alt trick works, what I was doing before that was having to close the most processor intensive thing when my CPU shouldn't even be stressing like Discord or Firefox. Another option I found right before finding this thread was pulling up the log out menu which somehow gets Godot running again.

Linux Mint 19.2, XFCE 4.12, Godot 3.2.1

[volzhs]

I changed to Kubuntu 20.04 from Linux Mint 19.3, and freezing is gone.

[agameraaron]

I changed to Kubuntu 20.04 from Linux Mint 19.3, and freezing is gone.

What Window Manager did you use with Linux Mint?

[volzhs]

I used mint cinnamon.

[peterkingsbury]

Tech specs:

Godot Engine v3.2.2.stable.mono.official
Mono JIT compiler version 6.10.0.104
Ubuntu 20.04.1 LTS 64-bit
Intel(R) Core(TM) i3-8100 CPU @ 3.60GHz
32Gb RAM (DDR4 3000)
NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] (rev a1)
gnome-shell 3.36.3

I'd been running Godot (same version as above) on Ubuntu 18.04.4 LTS (same system as above), and had intermittent freeze problems. Spent some time upgrading this past week, and noticing similar freezing.

• alt doesn't aways work
• project I noticed the freezing is on GLES3
• the most recent lockup occurred while changing the margin parameters of a VBoxContainer while 2D mode was open
• I've also had similar lockups occur while in the script editor

If there's more information I can provide I'd be happy to try.

2020-08-09

• Occurred while editing a NinePatchRect's Patch Margin parameters. Pressing alt did not cause the application to resume. Noticed this time around that 2 instances of ibus-daemon are pegging CPU at ~95% with ~4.6% (of 32GB) of system memory. Maybe it relates to this?

Edit: added Mono version
Edit 2: added 2020-08-09 entry.

[pouleyKetchoupp]

Could someone who can reproduce this issue consistently try with Godot 4.0?
https://archive.hugo.pro/builds/godot/master/editor/godot-linux-nightly-x86_64.zip
(Careful with your 3.2 projects as it breaks compatibility)

Also, if you're able to build Godot from source, I would be interested to know if building latest with this PR helps:
https://github.com/godotengine/godot/pull/41910

I'm not able to reproduce the issue myself on Ubuntu 20.04.1 / Gnome 3.36.3

[capnm]

I currently don't have access to the school's PCs, you know the COVID-19 mess. We use the VMware workstation system to manage hundreds of PCs. Your patch looks promising. We had to use an external text editor because in 3.x the text input became unusable laggy (Win10 + Ubuntu 20.04 inside VMware). Maybe someone can test this out in the free VMware Player ...

[pouleyKetchoupp]

@capnm Let me know if you need a 3.2 port of #41910 for test, it's a little bit of work but it should be doable.

[pouleyKetchoupp]

I went ahead and made a 3.2 backport anyway, because it can be useful to fix some other issues:
PR #42341

And I've made a Linux build based on 3.2.3 in case anyone would be willing to give it a try:
https://drive.google.com/file/d/1ZlAk1RR1SabwPzG3B2RRuD3B4R5xeJ5L/view?usp=sharing

Edit: The same change can also be tested in the 3.2.4 beta release:
https://downloads.tuxfamily.org/godotengine/3.2.4/beta1/

[capnm]

@pouleyKetchoupp thanks! I can test it when the on-site lessons start again on schedule in mid-October. I really appreciate that the 3.x still matters to some of you. I'm afraid that the hipped v4.0 may not be able to be used in practice on hardware in schools or even most children's hardware for a long time...