Description of problem:
starting glxgears with a remote X11 display hangs indefinitely
because libGL calls dri3_create_screen() even though
the display is remote.
with workaround LIBGL_DRI3_DISABLE=1 glxgears works fine
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. ssh -X somebox
2. gdb --args glxgears
no window shown, hangs forever in:
#0 0x00000030ec4f51c0 in __poll_nocancel () from /lib64/libc.so.6
#1 0x00000030f080a182 in _xcb_conn_wait () from /lib64/libxcb.so.1
#2 0x00000030f080ba8f in wait_for_reply () from /lib64/libxcb.so.1
#3 0x00000030f080bba1 in xcb_wait_for_reply () from /lib64/libxcb.so.1
#4 0x00000030fb04e869 in dri3_create_screen () from /lib64/libGL.so.1
#5 0x00000030fb01f9a1 in __glXInitialize () from /lib64/libGL.so.1
#6 0x00000030fb01c0ab in GetGLXPrivScreenConfig.part.2 () from /lib64/libGL.so.1
#7 0x00000030fb01c923 in glXChooseVisual () from /lib64/libGL.so.1
#8 0x0000000000403699 in make_window.constprop ()
#9 0x0000000000401a07 in main ()
some spinning wheels
Seems also to be the cause of this Xwayland/Gtk issue:
Fix is be easy enough, but I have no way of testing this atm. Anyone want to give this a spin?
diff --git a/dri3/dri3_request.c b/dri3/dri3_request.c
index fe45620..1249070 100644
@@ -92,6 +92,9 @@ proc_dri3_open(ClientPtr client)
+ if (!client->local)
+ return BadMatch;
status = dixLookupDrawable(&drawable, stuff->drawable, client, 0, DixReadAccess);
if (status != Success)
doodling about for a bit, i've now got a F21 chroot with RPMs
with the patch from comment #2, running that with systemd-nspawn -b
and ssh -X into it the problem is still there in a different place:
#0 0x00007ffff722e1c0 in __poll_nocancel () from /lib64/libc.so.6
#1 0x00007ffff4e3c182 in _xcb_conn_wait () from /lib64/libxcb.so.1
#2 0x00007ffff4e3da8f in wait_for_reply () from /lib64/libxcb.so.1
#3 0x00007ffff4e3dba1 in xcb_wait_for_reply () from /lib64/libxcb.so.1
#4 0x00007ffff7b8fa19 in dri3_open (provider=0, root=178, dpy=<optimized out>)
#5 dri3_create_screen (screen=0, priv=<optimized out>) at dri3_glx.c:1909
#6 0x00007ffff7b60aa1 in AllocAndFetchScreenConfigs (priv=0x612240,
dpy=0x606010) at glxext.c:788
#7 __glXInitialize (dpy=dpy@entry=0x606010) at glxext.c:902
#8 0x00007ffff7b5d1ab in GetGLXPrivScreenConfig (dpy=dpy@entry=0x606010,
ppsc=ppsc@entry=0x7fffffffdda8) at glxcmds.c:172
#9 0x00007ffff7b5da23 in GetGLXPrivScreenConfig (ppsc=0x7fffffffdda8,
ppriv=0x7fffffffdda0, scrn=0, dpy=0x606010) at glxcmds.c:168
#10 glXChooseVisual (dpy=0x606010, screen=0, attribList=0x7fffffffe000)
#11 0x0000000000403699 in make_window.constprop ()
#12 0x0000000000401a07 in main ()
*** Bug 1221168 has been marked as a duplicate of this bug. ***
Any further fix for this? It affects virt-viewer which uses GLX
and is often used remote over ssh.
I'm having a substantially similar issue. Logged into two different F21 machines, if I ssh to another machine (F21 or F22) and run, say, teapot or glxinfo, it will hang pretty much immediately. This is also breaking things like Matlab and Mathematica.
In addition to LIBGL_DRI3_DISABLE=1, LIBGL_ALWAYS_SOFTWARE=1 or LIBGL_ALWAYS_INDIRECT=1 also work (as is probably obvious).
I have, however, had this work when logging into a freshly installed F22 as a test user and then ssh'ing into the same machines where it failed. I need to try and understand why it worked at all.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.
(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)
More information and reason for this action is here:
... firefox, thunderbird, ...
Also happens on Rawhide/Fedora 24.
Michael, did you report the bug upstream?
(In reply to poma from comment #9)
> Also happens on Rawhide/Fedora 24.
What is the question for me ?
(In reply to poma from comment #9)
> Also happens on Rawhide/Fedora 24.
(In reply to poma from comment #10)
> Michael, did you report the bug upstream?
Why Michael? This bug was already fixed somewhere. If you cannot attach backtrace - please close bug.
no i didn't file an upstream bug for this (maybe somebody else did?).
on Fedora 23 i don't have this problem - but i don't know if Fedora 23 actually enables DRI3 by default and how to check that.
(In reply to Michael Stahl from comment #13)
> no i didn't file an upstream bug for this (maybe somebody else did?).
> on Fedora 23 i don't have this problem - but i don't know if Fedora 23
> actually enables DRI3 by default and how to check that.
As far as I know, DRI3 is not the default.
$ LIBGL_DEBUG=verbose vblank_mode=0 glxgears
using the following configuration:
Option "DRI" "3"
NOUVEAU(0): DRI3 on EXA enabled
Option "DRI3" "on"
RADEON(0): DRI3 enabled
Option "DRI" "3"
intel(0): direct rendering: DRI2 DRI3 enabled
GL/DRI3 over ssh broken
Resolved in xserver.
Created attachment 1122503 [details]
Fix DRI3 over ssh
Reported-by: Michael Stahl <firstname.lastname@example.org>
Suggested-by: Daniel Stone <email@example.com>
Tested-by: poma <firstname.lastname@example.org>
$ rpm --query --changelog xorg-x11-server-Xorg-1.18.1-2.fc22.x86_64
* Tue Feb 09 2016 poma <email@example.com> 1.18.1-2
- dri3: Refuse to work for remote clients (v2)
* Mon Feb 08 2016 Adam Jackson <firstname.lastname@example.org> 1.18.1-1
- xserver 1.18.1
* Mon Jan 04 2016 poma <email@example.com> 1.18.0-5
- os: Treat ssh as a non-local client (v3)
* Fri Dec 11 2015 poma <firstname.lastname@example.org> 1.18.0-4
- dri3: Refuse to work for remote clients
* Fri Dec 11 2015 poma <email@example.com> 1.18.0-3
- os: Treat ssh as a non-local client v2.1
*** Bug 1324505 has been marked as a duplicate of this bug. ***
*** Bug 1335183 has been marked as a duplicate of this bug. ***
*** Bug 1338069 has been marked as a duplicate of this bug. ***
This bug is still happening on Fedora 23 with:
I tested with 2 different remote machines, one with Fedora 23 and another one with Fedora 24. With Fedora 23, the workaround of disabling DRI3 works.
However, on the other machine with Fedora 23, disabling DRI3 makes the window to appear, but it causes a crash:
$ LIBGL_DRI3_DISABLE=1 LIBGL_DEBUG=verbose vblank_mode=0 glxgears
libGL error: failed to authenticate magic 7
libGL error: failed to load driver: i965
libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
ATTENTION: default value of option vblank_mode overridden by environment.
Illegal instruction (core dumped)
The workround of disabling DRI3 does not work for LibreOffice 188.8.131.52 under Fedora 23.
Created attachment 1168389 [details]
os: Treat ssh as a non-local client (v4)
The missing component to fix DRI3 over ssh (nouveau).
(In reply to Martin Gregorie from comment #23)
> The workround of disabling DRI3 does not work for LibreOffice 184.108.40.206 under
> Fedora 23.
firefox, thunderbird, libreoffice, ..., work OK
however glxgears (glx-utils-8.3.0-3.fc22.x86_64) over ssh (nouveau) is generally broken, i.e. not particularly to DRI v2 or v3
*** Error in `glxgears': free(): invalid pointer: 0x00007f75ed26c920 ***
======= Backtrace: =========
Its now working as of this evening's update, which delivered LibreOffice build 220.127.116.11-7.fc23, so I've now added 'export LIBGL_DRI3_DISABLE=1' to .bash_profile in the remote logins.
Thanks for the fix.
The last missed bit is part of released xserver 1.18.4
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 23 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.