Kitty occasionally crashes on mouseover

[LaserEyess]

Describe the bug
Kitty crashes when you move the mouse over the window when tmux/irssi is running

To Reproduce
Steps to reproduce the behavior:

1. Open a tmux window with irssi
2. Move mouse over it (???)
3. Occasionally it crashes

Expected behavior
No crash

Environment details
OS: Arch Linux
GPU: 5700 XT
Driver: amdgpu
WM: sway 1.5rc-1

kitty 0.18.1 created by Kovid Goyal
Linux mami 5.7.5-arch1-1 #1 SMP PREEMPT Mon, 22 Jun 2020 08:10:02 +0000 x86_64
Arch Linux \r (\l)
LSB_VERSION=1.4
DISTRIB_ID=Arch
DISTRIB_RELEASE=rolling
DISTRIB_DESCRIPTION="Arch Linux"
Loaded config files: /home/laser/.config/kitty/kitty.conf
Running under: Wayland

Config options different from defaults:
cursor_blink_interval 0.0
enable_audio_bell     False
font_size             12.0
foreground            Color(red=250, green=250, blue=250)
linux_display_server  wayland

Additional context
backtrace with debug symbols on glfw, kitty, and wayland https://0x0.st/iJV4.txt

Only a single kitty window seems to be doing this, my IRC window with irssi/tmux. Not sure if that's related.

[LaserEyess]

@kovidgoyal Still getting this crash occasionally. New backtrace: https://0x0.st/iwXv.txt

Kitty won't display a version other than 0.18.1 but I have a785b77

[kovidgoyal]

Hmm that looks like a bug in wayland, image should never be NULL, as long as the index passed in is les than image_count which kitty checks. I will add a workaround to kitty to just refuse to change the cursor if that happens, but the underlying bug is elsewhere.

[LaserEyess]

Another crash in the same function, but I couldn't get a backtrace because I fucked up my CFLAGS and couldn't get any info out of kitty. I'm in contact with wayland devs but they seem adamant that this is a bug in kitty. They've given me some suggestions such as using asan, but that's how I fucked up my CFLAGS so I need to learn what I'm doing first.

The difference is this crash didn't seem like a null pointer dereference.

#0  wl_cursor_image_get_buffer (_img=0x31) at ../wayland-1.18.0/cursor/wayland-cursor.c:166
        image = 0x31
        theme = <error reading variable theme (Cannot access memory at address 0x49)>
#1  0x00007fd2706df35b in setCursorImage.lto_priv.0 () from /usr/lib/kitty/kitty/glfw-wayland.so
No symbol table info available.
#2  0x00007fd2706e268c in animateCursorImage () from /usr/lib/kitty/kitty/glfw-wayland.so
No symbol table info available.
#3  0x00007fd2706e8b87 in dispatchTimers.part.0.constprop.0.isra.0 () from /usr/lib/kitty/kitty/glfw-wayland.so
No symbol table info available.
#4  0x00007fd2706d6a67 in glfwRunMainLoop () from /usr/lib/kitty/kitty/glfw-wayland.so
No symbol table info available.
#5  0x00007fd271077008 in main_loop.lto_priv () from /usr/bin/../lib/kitty/kitty/fast_data_types.so
No symbol table info available.

This is unfortunately all I have.

[kovidgoyal]

If you want to use asan, just do

make asan

Alternatively, if you can come up with a way to reproduce the crash
consistently, that would help me fix/workaround the issue.

[LaserEyess]

A completely different crash with the same symptoms, all I did was wave my mouse over the window and it crashed. However, this time in a very different place.

https://0x0.st/iwLF.txt

This could be a different bug, and I'm following up with people in #wayland to see if it's really not on their end.

[kovidgoyal]

That's again way inside libwayland. And simply waving the mouse around in kitty definitely doesnt crash for me. What's different about your wayland setup?? Animated mosue cursor theme? Some off-beat compositor??

[LaserEyess]

I have been struggling to reproduce this issue consistently, but I do not think my setup is strange. I use the default adwaita cursor theme, I have never set it anywhere, it's just what is used and it's what I have installed. I do not use any special compositor hacks, no special effects, no special anything.

In order to trigger this bug I have to do one of two things:

1. Mouse over the window
2. Have the cursor change types

I think 1 is actually related to 2 in that in order to trigger this crash the mouse over has to change cursor types, say from an arrow type to a text select type, or a finger type. No idea what those are called. However, just doing 1 or 2 is not enough, because I cannot trigger this bug just by causing the cursor to change type (by e.g. hovering over a link) or by mousing over kitty onto some text (by e.g. moving from firefox's arrow pointer to kitty's text select cursor). Therefore there's something I'm fundamentally missing about what is triggering the bug, it cannot just be the mouse over and cursor change, although that's definitely where kitty is crashing.

Something of note is that I have never seen this crash on my intel laptop (intel hd 630), this only happens on my AMD GPU (5700XT) desktop. Both are using identical setups: Arch, sway, and kitty 0.18.1. I've been having some issues with adaptive_sync on sway crashing in the kernel. Of course, implying that these are related to this kitty bug is a huge reach. But as it stands from my point of view the drivers and the hardware are the only things differing kitty sometimes crashing and kitty never crashing.

[kovidgoyal]

On Fri, Jul 24, 2020 at 06:41:48AM -0700, LaserEyess wrote: Something of note is that I have never seen this crash on my intel laptop (intel hd 630), this only happens on my AMD GPU (5700XT) desktop. Both are using identical setups: Arch, sway, and kitty 0.18.1. I've been having some issues with [adaptive_sync](swaywm/sway@380f4ac) on sway [crashing in the kernel](https://gitlab.freedesktop.org/drm/amd/-/issues/1216). Of course, implying that these are related to this kitty bug is a huge reach. But as it stands from my point of view the drivers and the hardware are the only things differing kitty sometimes crashing and kitty never crashing.

Well, if the issue is memory corruption, then bugs in video drivers can definitely cause it.

[LaserEyess]

Any way to help determine if that's a factor? I have asan for kitty enabled, and I think I may turn it on for libwayland at the suggestion of someone in #2715

By the way, also unrelated but asan is reporting a lot of memory leaks for kitty on closing.

[kovidgoyal]

On Fri, Jul 24, 2020 at 09:18:01AM -0700, LaserEyess wrote: Any way to help determine if that's a factor? I have asan for kitty enabled, and I think I may turn it on for libwayland at the suggestion of someone in #2715

Debugging GPU drivers is not something I have a lot of familiarity with.

By the way, also unrelated but asan is reporting a lot of memory leaks for kitty on closing.

I doubt any of them are from kitty code. Python itself leaks on exit.

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2810 (comment)

--

_____________________________________ Dr. Kovid Goyal https://www.kovidgoyal.net https://calibre-ebook.com

_____________________________________

[LaserEyess]

Finally got one with asan https://0x0.st/iwy_.txt

I think this one is the same but why not https://0x0.st/iwvj.txt

[kovidgoyal]

That's useful, wayland cursors are freed by libwayland. Looking at its
source code that is done when the wayland cursor theme is unloaded.
Unloading of themes was added in 7c3c87a for HiDPI cursor support.

Presumably what is happening is the cursor is being deleted on theme
unload but since GLFW is designed to refer directly to the cursor
pointer, that pointer is invalid after the unload. That entire GLFW
subsytem should be re-written to use indirect id based referenes to
themes and cursors within themes. To confirm my hypothesis, simply
comment out line 142 in wl_cursors.c that will prevent themes from being
unloaded and should fix your crash