[Bug] Crashes with multi-monitor setups
rsubtil opened this issue · 22 comments
There are reports of crashes when using komorebi with more than one monitor. I've been, for the last two weeks, trying to find a cause, but it's very hard to pinpoint the problem. However it's a very important issue, since it prevents stable usage of komorebi.
The crash in question looks like this:
(komorebi:17171): Gdk-ERROR **: 13:46:58.881: The program 'komorebi' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadDrawable'.
(Details: serial 448 error_code 160 request_code 152 (GLX) minor_code 29)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
And depending on the setup, it can be caused by:
- Simply launching komorebi (in my setup it doesn't occur, but in others it seems to crash reliably)
- Right-clicking "spamming" to open/close the bubble menu (which isn't "reliable", sometimes it happens quickly, other times takes a lot of times)
- Using other applications with komorebi open (again, not "predictable", but tends to happen 15-30min after launching)
This is all the "intel" I've been able to gather:
- This only happens when komorebi creates more than one window. It never crashed, no matter what I did, when I detached all my external monitors to only have one.
- Forcing komorebi to run with a single screen (
--single-screen) doesn't crash, even with another monitor plugged in. - Having komorebi spawn two windows on the same screen still causes it to crash.
- Having a picture or website wallpaper makes komorebi instantly crash, while a video wallpaper makes it crash much, much later.
- Messing with available environment flags (particularly
CLUTTER_DRIVER) doesn't help. - Commenting the code that adds the actors to the window (except the bubble menu) makes it "harder" to crash, but after fiddling with it, it still causes a crash
- Launching two separate instances of komorebi (one that displays on screen 1 and other on screen 2) doesn't crash
Judging from the "unpredictable" crashing behavior and the info above, I suspect there are some threading shenanigans going on.
Any help regarding this is much appreciated; for now, I'll keep investigations on hold until a language rewrite.
I'm having the same issue with the exception, that komorebi --single-screen is crashing too. It seems like komorebi is ignoring these flags on my System
I'm having the same issue with the exception, that komorebi --single-screen is crashing too. It seems like komorebi is ignoring these flags on my System
Are you sure you compiled the latest version of Komorebi? That argument was implemented a few weeks ago (#13), so there's no release yet with that new change.
No. I installed the latest release with the AUR. I will comment there, that they don't include this fix.
Thank you
CC @PJayB and @HakanIlbas
I remember fixing a similar issue on my fork a while ago. Will keep you up to date.
Cloned and launched your master, no crashes on my side. Video stream works on both monitors. Sadly this is the thing with Clutter. Its hard to pinpoint why there is an error. However i have an idea what could fix it, since i had the same issue before. I remember changing Gdk.Screen to Gdk.Display, since most of Gdk.Screen its functions are deprecated.
In main.vala you do
var screen = Gdk.Screen.get_default ();
int monitorCount = hasArg("--single-screen", args) ? 1 : screen.get_n_monitors();
@cheesecakeufo used to do this as well. However Gdk.Screen.get_default.get_n_monitors() is deprecated
In my fork i use Gdk.Display which is very similar to Gdk.Screen. In my fork i do
var display = Gdk.Display.get_default ();
int monitorCount = display.get_n_monitors();
I remember that after doing this I fixed the crash i had at the time.
However, like I said, your master does not crash on my multiple screen setup and I dont know why because i remember having the same issue.
EDIT: It was also the first commit I made on my fork. You can see the changes here
Thank you, I've tried your changes as well, but it still crashes. This is a really weird bug, I'm almost convinced it's some problem with Clutter and/or GDK itself. I'll see if I can create a small reproduction project and file a bug report there.
Can you quickly clone and build my fork. If multi monitor setups work with my fork on your setup, the ctash is caused by one of the changes you guys made. If not you can sort of confirm if it is a Clutter problem
I tried now building the latest version of this repository and it's working with the --single-screen flag, but not without it. The Fork from HakanIlbas is not working.
But I should mention that my monitor setup is not very common. I have 2 1920x1080p displays that show the same (they are mirrored) and left from them is a old 1280x1024p display. Maybe it would work, if all had the same resolution.
@Donald4444 can you try both forks with your 1280x1024p display unplugged and only with your two 1920x1080p displays (mirrored and with one screen extending the other)
Both forks work for me, my setup is an ASUS GL553VD, using the dedicated GTX 1050 graphics card with a 15inch laptop screen and an external 29 inch 2560x1080 ultra wide display.
It could be a graphics card problem as well, as i remember my fork not working that well when i use my intel hd graphics. i Use the following environment variables to get it somewhat running stable:
LIBGL_ALWAYS_INDIRECT=1
GDK_SYNCHRONIZE=1
I'm using an R9 270X. I can decide with that between the amdgpu driver (newer but experimental) and the ati driver (older, but not experimental). The architecture is GCN 1. I'm currently using the amdgpu driver, since the ati driver had some problems.
https://wiki.archlinux.org/index.php/Xorg#AMD
Both don't work with the enviroment variables.
Welcome to Komorebi
amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-13)
amdgpu: amdgpu_device_initialize failed.
(komorebi:143201): Cogl-WARNING **: 20:34:45.848: winsys/cogl-winsys-egl-kms.c:771: Error restoring saved CRTC
Reading config file..
[INFO]: loading Gst
(komorebi:143201): Gdk-CRITICAL **: 20:34:45.987: gdk_visual_get_screen: assertion 'GDK_IS_VISUAL (visual)' failed
(komorebi:143201): Gdk-CRITICAL **: 20:34:45.987: gdk_window_new: assertion 'gdk_visual_get_screen (attributes->visual) == screen' failed
(komorebi:143201): Gdk-CRITICAL **: 20:34:45.987: gdk_window_get_width: assertion 'GDK_IS_WINDOW (window)' failed
(komorebi:143201): Gdk-CRITICAL **: 20:34:45.987: gdk_window_get_height: assertion 'GDK_IS_WINDOW (window)' failed
Speicherzugriffsfehler (Speicherabzug geschrieben)
dmesg gives additional info:
[ 7304.826934] komorebi[147353]: segfault at 18 ip 00007f45cab35188 sp 00007fff6cc3d1d8 error 4 in libgdk-3.so.0.2404.17[7f45cab12000+7d000]
| Display mode | This fork | This fork with --single-screen |
@HakanIlbas fork |
|---|---|---|---|
| Mirrored | Not working¹ | Working | Not working¹ |
| Extended | Not working¹ | Working | Not working¹ |
Note: I changed the mode in the KDE-Settings. I only used both 1920x1080p monitors, so I would guess it isn't the resolution that causes the crash.
¹Crashes with
[mika@MikaArchLinux build]$ ./komorebi
Welcome to Komorebi
Reading config file..
[INFO]: loading Gst
(komorebi:164740): Gdk-ERROR **: 20:52:44.868: The program 'komorebi' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadDrawable'.
(Details: serial 495 error_code 160 request_code 152 (GLX) minor_code 29)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/Breakpoint ausgelöst (Speicherabzug geschrieben)
I hope this helps fixing the Bug. I found an another way to play videos as background, but if you need me testing things against this bug just comment it. I will leave the notifications on.
@HakanIlbas I just tried a fresh clone of your fork, and even using LIBGL_ALWAYS_INDIRECT=1 GDK_SYNCHRONIZE=1, but no luck 😕
With those environment flags it segfaulted before even launching, but it's probably hybrid graphics shenanigans from my side.
very sad :/
Unfortunately, I haven't found a way to successfully debug komorebi, even with GDB its not really clear why it is crashing. There is also not much information out there about how to debug Vala or Clutter or to why a GLXBadDrawable error occurs.
Perhaps it is an issue that has to do with Clutter not working optimally with AMD graphics cards or their drivers. All issues that i have seen so far happened on AMD graphics cards.
Nope, this issue happens with Nvidia as well (and in my setup it's hybrid graphics, so it's using Intel). So it shouldn't be graphics problem.
After reaching out for help on some IRC channels, the consensus is that Clutter and/or the integration with GTK is just not maintained anymore and prone to problems. However I don't know any other sort of backend that we could replace Clutter with...
After a bit more investigation, I'm deeply convinced we simply shouldn't use Clutter anymore; it's a "limbo" project, where it's development is dead, but at the same time not.
This is a portion of the project's README.md:
Clutter is in deep maintenance mode; only micro releases addressing bug fixes are planned from now on. Additionally, the API and features are frozen.
The planned replacement for Clutter is GTK 4.0.
If you are fixing a bug in Mutter then please open a merge request against the internal copy of Clutter inside that project.
I was also suggested on multiple IRC channels not use Clutter and consider using GTK4, when it comes out (which should release this year)
So, I don't think this issue will be solved without a major rework on how komorebi works. At this point I'm pretty sure this is some problem of multi-threading and/or shared memory space, as having two instances of komorebi running separately never caused this crash. We could offer a solution based on this (having for example komorebi fork itself to the number of available screens), but it will always be a dirty way to fix this properly.
Until GTK4 is fully released and ready for usage, I don't see a good way to fix this, as it's an issue with the backend we're using, and not the project itself.
Quick update: I was able to create a reproduction project, and have submitted a bug report.
Nice, but the project isnt being actively worked on anymore. No commits in the last 11 months
+1, this is stopping me from being able to properly use Komorebi