Crash when editing text in LineEdit/TextEdit on Linux/Wayland

[em-s-h]

Tested versions

• Reproducible in: 4.3.stable

System information

Godot v4.3.stable unknown - Arch Linux #1 SMP PREEMPT_DYNAMIC Thu, 02 Jan 2025 22:52:26 +0000 - Wayland - Vulkan (Forward+) - integrated Intel(R) HD Graphics 5500 (BDW GT2) - Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz (4 Threads)

Issue description

I've had this crash happen 3 times to me so far:

1. When I clicked in the TextEdit preview of the theme editor;
2. Happened when clicking the Text field of a button after changing it's icon;
3. Happened when editing a signal's callback method in the node tab on the godot editor.

Only the 3rd crash had a backtrace with debug symbols:

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.3.stable.custom_build (77dcf97d82cbfe4e4615475fa52ca03da645dbd8)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x3d1d0) [0x7a98136411d0] (??:0)
[2] /usr/lib/libwayland-client.so.0(wl_proxy_get_version+0x4) [0x7a980eb6dd24] (??:0)
[3] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x685366) [0x5bca04b7e366] (/home/esh/aur/godot/platform/linuxbsd/wayland/protocol/primary_selection.gen.h:361 (discriminator 1))
[4] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x66cda9) [0x5bca04b65da9] (/home/esh/aur/godot/platform/linuxbsd/wayland/display_server_wayland.cpp:468)
[5] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x2d6acd9) [0x5bca07263cd9] (/home/esh/aur/godot/./core/templates/cowdata.h:477)
[6] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x2af0d27) [0x5bca06fe9d27] (/home/esh/aur/godot/scene/main/viewport.cpp:1570 (discriminator 1))
[7] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x2b0012f) [0x5bca06ff912f] (/home/esh/aur/godot/./core/object/ref_counted.h:223)
[8] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x2b1b48c) [0x5bca0701448c] (/home/esh/aur/godot/./core/object/ref_counted.h:209)
[9] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x2b1a411) [0x5bca07013411] (/home/esh/aur/godot/./core/object/ref_counted.h:209)
[10] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x2b1b64d) [0x5bca0701464d] (/home/esh/aur/godot/scene/main/viewport.cpp:3242 (discriminator 1))
[11] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x2b6c6b1) [0x5bca070656b1] (/home/esh/aur/godot/./core/object/ref_counted.h:209)
[12] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x66e893) [0x5bca04b67893] (/home/esh/aur/godot/./core/variant/variant.h:308)
[13] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x4c62b07) [0x5bca0915bb07] (/usr/include/c++/14.2.1/x86_64-pc-linux-gnu/bits/gthr-default.h:762)
[14] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x4c657ed) [0x5bca0915e7ed] (/home/esh/aur/godot/./core/object/ref_counted.h:209)
[15] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x611130) [0x5bca04b0a130] (/home/esh/aur/godot/platform/linuxbsd/os_linuxbsd.cpp:960)
[16] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x5e8982) [0x5bca04ae1982] (/home/esh/aur/godot/platform/linuxbsd/godot_linuxbsd.cpp:85)
[17] /usr/lib/libc.so.6(+0x25e08) [0x7a9813629e08] (??:0)
[18] /usr/lib/libc.so.6(__libc_start_main+0x8c) [0x7a9813629ecc] (??:0)
[19] /home/esh/aur/godot/bin/godot.linuxbsd.editor.x86_64(+0x60df15) [0x5bca04b06f15] (??:?)
-- END OF BACKTRACE --
================================================================

I can include the other backtraces if necessary.

Steps to reproduce

I've not found a way to consistently perform this crash, it seems like it happens at random when I interact with a text field on the editor.

Minimal reproduction project (MRP)

N/A

[xsellier]

Hey,

sorry for that crash. Meanwhile I tried to reproduce it on my own Debian, I'm not using Wayland but X11, and so far no crash.
here a record of the tests I've made so far:

line-edit-textedit-working.webm

[Riteo]

Hi, thank you for your report and for the nice backtrace!

It reports that it's related to the primary selection, which is set by selecting text and can be pasted with the middle mouse button.

Taking a look at the code, it looks like we're missing a check for the validity of its reference, so we try to dereference a null pointer and there goes the crash.

Perhaps you unfocus right while selecting text and the primary selection goes away? Maybe you have some clipboard manager. No idea either.

The fix should be trivial. I'll make a PR with that check soon!

[em-s-h]

Perhaps you unfocus right while selecting text and the primary selection goes away? Maybe you have some clipboard manager. No idea either.

My mouse has a problem where it will sometimes send 2 click inputs very quickly, that must be why the crashes were happening.

[Riteo]

My mouse has a problem where it will sometimes send 2 click inputs very quickly, that must be why the crashes were happening.

Ooooh then perhaps you're focusing and selecting at the same time. That makes a lot of sense.

[em-s-h]

@Riteo Just got this crash again and I wanted to ask something that I'd forgotten to mention, is it normal for this type of crash to make Godot use a lot of memory?

[Riteo]

@em-s-h mhh... Not sure exactly what you're talking about. I mean, once it crashes it crashes.

I know though that we have a custom crash handler that prints a stack trace and that might cause higher memory consumption while it figures things out. For reasons I almost never see that code running, so I might be completely wrong.

[em-s-h]

I know though that we have a custom crash handler...

Maybe that's it, since it does take a while for Godot to close after crashing, but this is the only crash where this has happened to me

[Riteo]

Hi, I made a PR over at #101799, could you please try it and confirm me that it fixes the issue?

[em-s-h]

I don't know if I'll be able to confirm this fix, since the mouse malfunction happens very rarely, and I have no other way of replicating it.

[Riteo]

@em-s-h no worries! I think that the stack trace you attached is enough evidence for a check to be there, tested or not.

In a weird twist of fate, surprisingly, I... just started getting this issue constantly 😅

I think I can see myself whether the fix works now XD