Occasionally freeze when moving the mouse in the editor

[Rindbee]

Godot version

f692b47

System information

Linux mint 21, forward_plus ,NVIDIA GeForce GTX 1050 Ti

Issue description

I occasionally get stuck when moving the mouse in the editor. I have encountered it many times so far, but I have not explored the specific cause. Cannot use the screenshot tool to take a screenshot after being stuck.

Recently I tried to reproduce it by just moving the mouse, and I only succeeded once, but still can't find any reproducible steps. Might be related to the tooltip popup. When the popup does not disappear with the mouse movement, it means that it has been stuck.

I use i3wm, prone to this problem in the following situations.

1. When switching workspaces, you may need to stay in other workspaces for a while;
2. Or let the editor display on the screen, leave the computer for a while and use the mouse to move again.

Just using the mouse to move in the editor will also encounter this issue.

There are no signs or messages. Might be related to #69582, I'm not sure.

Steps to reproduce

Sorry, this issue came up by accident and I'm not sure of the exact steps to reproduce.

Minimal reproduction project

N/A

[timothyqiu]

I was just about to report the same issue 👍

I use Arch Linux and was using a 3.x custom build. I once succeeded reproducing the freeze by attaching a new script, typing some export variable declaration, and randomly clicking the mouse. But those steps no longer work now.

When I was able to reproduce the freeze with gdb on, interrupting the process shows that the main thread is stuck at a pthread mutex lock inside the XSetICValues() in OS_X11::set_ime_position() (called by TextEdit::_notification()). I'm not sure if this is related to the freeze.

godot/platform/x11/os_x11.cpp

Lines 828 to 848 in f128170

	void OS_X11::set_ime_position(const Point2 &p_pos) {
	im_position = p_pos;
	if (!xic) {
	return;
	}
	::XPoint spot;
	spot.x = short(p_pos.x);
	spot.y = short(p_pos.y);
	XVaNestedList preedit_attr = XVaCreateNestedList(0, XNSpotLocation, &spot, NULL);
	{
	// Block events polling during this call
	// because it triggers some event polling internally.
	MutexLock mutex_lock(events_mutex);
	XSetICValues(xic, XNPreeditAttributes, preedit_attr, NULL);
	}
	XFree(preedit_attr);
	}

[lawnjelly]

Notable all reports are on linux. Has this occurred before or is it recent?

Most recent PR is #69943. (If this is occurring on 3.x and master).

Just looking at that PR, I can see a possible problem:

void JoypadLinux::monitor_joypads() {
	while (!monitor_joypads_exit.is_set()) {
		DIR *input_directory;
		input_directory = opendir("/dev/input");
		if (input_directory) {
			struct dirent *current;
			char fname[64];
			while ((current = readdir(input_directory)) != nullptr) {
				if (strncmp(current->d_name, "event", 5) != 0) {
					continue;
				}
				sprintf(fname, "/dev/input/%.*s", 16, current->d_name);
				if (attached_devices.find(fname) == -1) {
					open_joypad(fname);
				}
			}
		}
		closedir(input_directory);
		usleep(1000000); // 1s
	}
REMOVED	usleep(1000000); // 1s
}

How often is monitor_joypads() called? Should there be a sleep in both locations?

Yes, it looks like there might be a thread continuously calling this function. It may not be a cause of this issue but it's making me suspicious enough to make a PR.

Ok scratch that, this PR was merged after 3.5.1, so can't be responsible for the 3.5.1 freeze, and we now think the while loop should be running till exit, so the last sleep would only occur on exit.

[KaziiTheAvali]

i have this problem too. the current and only seaming work around is using 3.2.3 as that is the latest working version. 3.3.x breaks in the same way as 3.5.1

i hope this helps some

EDIT: another work around is going through lutris(and wine) with the windows version of godot.

[artyommironov]

Void Linux, Wayland, Sway 1.8.2. Godot 3.5.1 constantly freezes in the editor after few minutes of work. As @timothyqiu mentioned set_ime_position() I thought maybe IME is causing this issue. I had fcitx5 running as IME, when I stop it Godot works without freezing.

[lawnjelly]

BTW for anyone getting this, it would be really helpful to know how far back in terms of versions this freezing happens, because it might help pinpoint which change might be responsible (i.e. if you download some old builds 3.4, 3.3 etc and see if you can work out how far back this was happening, or when it started).

[artyommironov]

it would be really helpful to know how far back in terms of versions this freezing happens

For me it seems:

• 3.2.3 no issue
• 3.2.4-beta1 has issue

This commit happened between these versions and looks related.

[lawnjelly]

This commit happened between these versions and looks related.

That indeed looks likely as it looks like the events_mutex might have been responsible in @timothyqiu 's bit of code, and that was introduced in #42341 .

There's also not a great deal of commits in this area over the past few years, which makes it easier to pin down (this @pouleyKetchoupp one and another mouse one by Aaron was the only ones I spotted recently).

Although this is most likely to do with introduction of the input thread, I had to google what IME meant in the set_ime_position() function. It seems it is to do with the selection box that opens to allow selecting characters in e.g. chinese (i.e. non-english languages). By any chance are all you guys with this problem using non-english language? Or has anyone reproducing this with english input? This is just a wild hunch but might help narrow down a little.

This will likely require someone who can reproduce the problem to fix, maybe by commenting in and out bits of code to try and pin down the culprit.

Also I noticed several concerns raised in #41910 (the original master version) about threading and locking.

[Zireael07]

IME stands for Input Method Editors and it is mostly used in Asian languages. (Arabic uses a RTL keyboard layout, which does not need an IME)

[artyommironov]

By any chance are all you guys with this problem using non-english language? Or has anyone reproducing this with english input?

@lawnjelly I use IME (fcitx5) for Japanese input occasionally, but I only use English layout in Godot. In fact, to reproduce the freeze I don't even need to input anything, just start selecting text in the editor with mouse and moving the mouse cursor around, same as @Rindbee mentioned in the description. Just a guess, as I'm not familiar with the code, when we select text it seems got auto-copied to PRIMARY clipboard, there is a mutex lock in OS_X11::set_clipboard maybe it got dead-locked somehow with the one in OS_X11::set_ime_position.

[Zireael07]

when we select text it seems got auto-copied to PRIMARY clipboard

That's a system thing not a Godot thing

[artyommironov]

That's a system thing not a Godot thing

True, I was confused by PRIMARY mentioned in set_clipboard, but after some checking it turns out copying is not happening during selection, actually it happens when paste event triggered somewhere.

[Rindbee]

It seems that a thread is reserved when compiling (scons -j$((`nproc` - 1)), use scons -j$(nproc) the situation will be better, may be an illusion?), and it is easier to reproduce this issue in the editor. I'm stuck in the following situations in a7276f1:

1. After creating a new project, it is stuck in the import progress bar;
2. After the OptionButton pops up the options;
3. When renaming the node name in the Scene dock.
4. Tooltips.

After freezing, when switching to other workspaces, there will often be a pop-up window that will not disappear.