Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Kitty occasionally crashes on mouseover #2810

Closed
LaserEyess opened this issue Jun 29, 2020 · 15 comments
Closed

Kitty occasionally crashes on mouseover #2810

LaserEyess opened this issue Jun 29, 2020 · 15 comments
Labels
bug

Comments

@LaserEyess
Copy link

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 LaserEyess added the bug label Jun 29, 2020
@LaserEyess
Copy link
Author

@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
Copy link
Owner

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
Copy link
Author

LaserEyess commented Jul 21, 2020 •
edited

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
Copy link
Owner

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
Copy link
Author

LaserEyess commented Jul 23, 2020 •
edited

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
Copy link
Owner

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
Copy link
Author

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
Copy link
Owner

kovidgoyal commented Jul 24, 2020 via email

@LaserEyess
Copy link
Author

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
Copy link
Owner

kovidgoyal commented Jul 24, 2020 via email

@LaserEyess
Copy link
Author

LaserEyess commented Jul 24, 2020 •
edited

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
Copy link
Owner

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

kovidgoyal added a commit that referenced this issue Jul 25, 2020
@kovidgoyal
Simplify Wayland cursor theme handling
6f40b8d 
Now themes are loaded once per scale and stored centrally not per
window. They are not unloaded till application shutdown. Since there
is unlikely to be more than two or three scales this is not a big waste
of resources. Since cursor lifetime is tied to theme lifetime and cursors
are stored per window, destroying a theme requires destroying all
cursors win all windows referring to that theme, which is too much work.

Should hopefully fix #2810
@kovidgoyal
Copy link
Owner

Since I havent heard from you yet, I decided to go ahead and implement
the fix, it anyway greatly simplifies the code at the cost of a litte more
memory usage. Hopefully, your issue is now fixed, I have no way tobe
certain since I cannot reproduce.

@LaserEyess
Copy link
Author

I just rebuilt from master again, and I'm going to be using this for a while to see if it crashes again.

@LaserEyess
Copy link
Author

I have not seen a crash in about 4 days, usually it would be much easier to trigger this bug. I think this is the solution, thanks so much for your patience and ultimately the fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@kovidgoyal @LaserEyess