I run Arch Linux and I have 2 Nvidia GPUs: GPU0: GTX 1070, 2 monitors connected (1920x1080; 2560x1080-primary) GPU1: GTX 1080 Ti, 0 monitors connected (dummy monitor in xorg.conf) There are 2 X screens in xorg.conf: Screen0 and Screen1, the latter lets me use Coolbits for GPU1 and adjust its fan speed manually If I comment out Screen1, everything works. If I don't, xfwm4 with compositing enabled crashes immediately (this didn't happen in 4.13). If compositing is disabled or I run compton instead or I run mutter instead of xfwm4, everything works as intended. Command Line: xfwm4 --replace --display :0.0 --sm-client-id 2be212a7b-fe4b-47f8-989a-70731ad66371 Executable: /usr/bin/xfwm4 Control Group: /user.slice/user-1000.slice/session-2.scope Stack trace of thread 52498: #0 0x00007f62cbe30fc6 _g_log_abort (libglib-2.0.so.0) #1 0x00007f62cbe2e71c g_log_writer_default (libglib-2.0.so.0) #2 0x00007f62cbe24f19 g_log_structured_array (libglib-2.0.so.0) #3 0x00007f62cbe2684b g_log_structured_standard (libglib-2.0.so.0) #4 0x00007f62cc167767 _gdk_x11_display_error_event (libgdk-3.so.0) #5 0x00007f62c3b923a6 n/a (libGLX_nvidia.so.0) #6 0x00007f62c3b8aa10 glXBindTexImageEXT (libGLX_nvidia.so.0) #7 0x000055c979c468ca bind_glx_texture (xfwm4) #8 0x00007f62cbe36194 g_timeout_dispatch (libglib-2.0.so.0) #9 0x00007f62cbe369a9 g_main_dispatch (libglib-2.0.so.0) #10 0x00007f62cbe389c9 g_main_context_iterate (libglib-2.0.so.0) #11 0x00007f62cbe39963 g_main_loop_run (libglib-2.0.so.0) #12 0x00007f62cc4b353f gtk_main (libgtk-3.so.0) #13 0x000055c979c3b92c main (xfwm4) #14 0x00007f62cb764ee3 __libc_start_main (libc.so.6) #15 0x000055c979c3bc1e _start (xfwm4) Stack trace of thread 52500: #0 0x00007f62cb82f667 __poll (libc.so.6) #1 0x00007f62cbe38930 g_main_context_poll (libglib-2.0.so.0) #2 0x00007f62cbe39963 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f62cb0406e8 gdbus_shared_thread_func (libgio-2.0.so.0) #4 0x00007f62cbe144e1 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f62cb90a57f start_thread (libpthread.so.0) #6 0x00007f62cb83a0e3 __clone (libc.so.6) Stack trace of thread 52499: #0 0x00007f62cb82f667 __poll (libc.so.6) #1 0x00007f62cbe38930 g_main_context_poll (libglib-2.0.so.0) #2 0x00007f62cbe38a11 g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f62cbe38a62 glib_worker_main (libglib-2.0.so.0) #4 0x00007f62cbe144e1 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f62cb90a57f start_thread (libpthread.so.0) #6 0x00007f62cb83a0e3 __clone (libc.so.6)
Created attachment 8917 xorg.conf
Created attachment 8918 xfwm4 debug log
Created attachment 8919 coredump info
Created attachment 8920 valgrind log
Created attachment 8921 xorg.conf generated by nvidia-xconfig --enable-all-gpus Same with xorg.conf generated by nvidia-xconfig --enable-all-gpus && nvidia-xconfig --cool-bits=28
Created attachment 8923 coredumpctl gdb bt
Comment on attachment 8923 coredumpctl gdb bt Each run of xfwm4 usually generates 6 core dumps, but I don't see any difference in their gdb backtraces. Mon 2019-08-19 17:57:30 +05 51653 1000 100 5 present /usr/bin/xfwm4 Mon 2019-08-19 17:57:31 +05 52442 1000 100 5 present /usr/bin/xfwm4 Mon 2019-08-19 17:57:32 +05 52470 1000 100 5 present /usr/bin/xfwm4 Mon 2019-08-19 17:57:33 +05 52480 1000 100 5 present /usr/bin/xfwm4 Mon 2019-08-19 17:57:33 +05 52498 1000 100 5 present /usr/bin/xfwm4 Mon 2019-08-19 17:57:34 +05 52516 1000 100 5 present /usr/bin/xfwm4
Edit: this didn't happen in 4.12.5, not 4.13, I haven't tested it.
So, this happens with --vblank=gtx, but everything works with --vblank=xpresent. There are 2 small issues when restarting xfwm4 --replace on the fly, though: 1. After the xfwm4 restart, all already opened windows now have some right invisible vertical border depending on their size you cannot drag them through. If you try to maximize the window, it will fill some small area in top left corner of the left screen. But resizing windows still works, I can drag the right border of every window to the right, even to the right screen, and it will resize fine, but the new invisible vertical border will move to the new position of the right border. Anyway, this is solved by unchecking Primary display in Display settings, if I check it again the issue doesn't return. https://i.imgur.com/Je2NGvY.png 2. xfwm4 restarts without issues only after disabling and re-enabling display compositing in Window Manager Tweaks, if I don't do that, title bars don't appear or all previous window positions remain on the screen, so this looks like final effects in Microsoft Solitaire.
Let's focus on the crash. Which was the latest version of 4.13 which was known to be working?
Ah sorry, forget that, comment 8 states it worked in 4.12 no 4.13.
Ah sorry, forget that, comment 8 states it worked in 4.12, not 4.13
Olivier Fourdan referenced this bugreport in commit 3925109d09614f95a5ef96b35db686d889457af0 compositor: Don't repaint a screen of zero size https://git.xfce.org/xfce/xfwm4/commit?id=3925109d09614f95a5ef96b35db686d889457af0
Olivier Fourdan referenced this bugreport in commit 699c0aeb782cb36181d2cd6fe39804363c23fb8c common: There might be no primary monitor https://git.xfce.org/xfce/xfwm4/commit?id=699c0aeb782cb36181d2cd6fe39804363c23fb8c
Can you please try to see if current master works now?
With current master (4.14.0+12+g99352a080): no more Gdk-CRITICAL ... assertion 'GDK_IS_MONITOR (monitor)' failed in xfwm4 logs, but it still crashes when using glx compositing. I'll attach coredumpctl gdb bt (again, there are 6 generated each time, but they are basically the same, only values differ) and xfwm4 debug log.
Created attachment 8969 coredumpctl gdb bt (4.14.0+12+g99352a080)
Created attachment 8970 xfwm4 debug log (4.14.0+12+g99352a080)
This is not a crash, it's an abort due to an XError. I suspect this is because the second screen with no output is of size 0, but I could be wrong. From the core file in gdb, an you please post the result of: (gdb) bt full (gdb) f 8 (gdb) p *screen_info
Created attachment 8999 bt full (4.14.0+12+g99352a080)
Created attachment 9000 f 8 (4.14.0+12+g99352a080)
Created attachment 9001 p *screen_info (4.14.0+12+g99352a080)
Created attachment 9002 p *screen_info (4.14.0+12+g99352a080)
I'm following up here from my original bug report #16374: https://bugzilla.xfce.org/show_bug.cgi?id=16374 Short summary for convenience: I'm running Xubuntu, with similar xfwm4 crashing after upgrade from 19.04 to 19.10. I have a single Nvidia K4000 GPU with two 4K monitors attached to DP-2 and DP-3. Upon boot I would get a desktop on Screen-0 but no xfce4-panel and a crashing xfwm4. (See backtrace on other bug report.) Screen-1 was blank. I could start various programs on both Screen-0 and also on Screen-1, but functionality without a window manager was very crippled. After reading this thread carefully, I commented out Screen-1 in the server section of my /etc/X11/xorg.config file and rebooted. Upon logging in, Xubuntu started as expected on Screen-0. I have my desktop, panel, window manager and my eight workspaces as previously defined under 19.04. With this configuration, Screen-1 was an exact mirror of Screen-0 rather than an independent monitor. I turned it off/on and got an Nvidia setup screen that allowed me to extend screen-1 to the right of Screen-0. It is now functioning as if in Xinerama mode, even though this is still set to off in xorg.conf. (I'll see what happens automatically when I reboot after finish this note.) Under 19.04 with the same xorg.conf file, Screen-1 was an independent monitor and although it was not possible to run a second desktop or panel on it, apparently due to features in xfwm4 I was able to launch programs from screen-0 to display on screen-1 and I had eight completely independent workspaces on that screen as well. This is the minimal functionality I wish to restore, which I believe will be possible if we can solve the problem of xfwm4 crashing when the second screen is defined. Here is my current xorg.conf file with the single Screen-1 line commented out. # nvidia-settings: X configuration file generated by nvidia-settings # nvidia-settings: version 430.50 Section "ServerLayout" Identifier "Layout0" Screen 0 "Screen0" 0 0 # Screen 1 "Screen1" LeftOf "Screen0" InputDevice "Keyboard0" "CoreKeyboard" InputDevice "Mouse0" "CorePointer" Option "Xinerama" "0" EndSection Section "Files" EndSection Section "InputDevice" # generated from default Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/psaux" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" # generated from default Identifier "Keyboard0" Driver "kbd" EndSection Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor0" VendorName "LG" ModelName "27UK650-W" HorizSync 30.0 - 135.0 VertRefresh 56.0 - 61.0 Option "DPMS" EndSection Section "Monitor" # HorizSync source: edid, VertRefresh source: edid Identifier "Monitor1" VendorName "LG" ModelName "27UK650-W" HorizSync 30.0 - 135.0 VertRefresh 56.0 - 61.0 Option "DPMS" EndSection Section "Device" Identifier "Device0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "Quadro K4000" BusID "PCI:4:0:0" Screen 0 EndSection Section "Device" Identifier "Device1" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "Quadro K4000" BusID "PCI:4:0:0" Screen 1 EndSection Section "Screen" Identifier "Screen0" Device "Device0" Monitor "Monitor0" DefaultDepth 24 Option "Stereo" "0" Option "metamodes" "DP-3: 3840x2160_60 +0+0" Option "SLI" "Off" Option "MultiGPU" "Off" Option "BaseMosaic" "off" SubSection "Display" Depth 24 EndSubSection EndSection Section "Screen" Identifier "Screen1" Device "Device1" Monitor "Monitor1" DefaultDepth 24 Option "Stereo" "0" Option "metamodes" "DP-2: 3840x2160_60 +0+0" Option "SLI" "Off" Option "MultiGPU" "Off" Option "BaseMosaic" "off" SubSection "Display" Depth 24 EndSubSection EndSection
One more piece of information. I had also lost proper audio operation after the upgrade. Once the changes noted above were made and xfwm4 was running properly, I discovered that proper audio operation was restored. I'm thinking that there may have been some sort of attempt to channel the audio through the Nvidia K4000 GPU to non-existent speakers in the monitor. That's just a guess. Anyway, audio seems to be somehow related to this failure.
Olivier Fourdan referenced this bugreport in commit 25eca2752133467d1cdb366c9557ebd62fb28143 compositor: Really avoid painting a screen of zero size https://git.xfce.org/xfce/xfwm4/commit?id=25eca2752133467d1cdb366c9557ebd62fb28143
Olivier Fourdan referenced this bugreport in commit 91133dfb0d65e5c2a720ab0700e12833f1f64cc3 compositor: Don't repaint a screen of zero size https://git.xfce.org/xfce/xfwm4/commit?id=91133dfb0d65e5c2a720ab0700e12833f1f64cc3
Olivier Fourdan referenced this bugreport in commit 95f3bf128ec4bd5a37429923a3486aa32993592d common: There might be no primary monitor https://git.xfce.org/xfce/xfwm4/commit?id=95f3bf128ec4bd5a37429923a3486aa32993592d
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/342. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev