Seems also to be the cause of this Xwayland/Gtk issue:
https://bugzilla.gnome.org/show_bug.cgi?id=741011

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
--- a/dri3/dri3_request.c
+++ b/dri3/dri3_request.c
@@ -92,6 +92,9 @@ proc_dri3_open(ClientPtr client)

     REQUEST_SIZE_MATCH(xDRI3OpenReq);

+    if (!client->local)
+       return BadMatch;
+
     status = dixLookupDrawable(&drawable, stuff->drawable, client, 0, DixReadAccess);
     if (status != Success)
         return status;

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:

(gdb) bt
#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>)
    at dri3_glx.c:1670
#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, 
    scrn=scrn@entry=0, ppriv=ppriv@entry=0x7fffffffdda0, 
    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)
    at glxcmds.c:1249
#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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

... 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:

/etc/X11/xorg.conf.d/nouveau-dri3.conf
Section "Device"
	Identifier  "nvidia0"
	Driver      "nouveau"
	Option      "DRI" "3"
EndSection

Xorg.0.log:
NOUVEAU(0): DRI3 on EXA enabled
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/etc/X11/xorg.conf.d/radeon-dri3.conf
Section "Device"
	Identifier  "amd0"
	Driver      "radeon"
	Option      "DRI3" "on"
EndSection

Xorg.0.log:
RADEON(0): DRI3 enabled
~~~~~~~~~~~~~~~~~~~~~~~

/etc/X11/xorg.conf.d/intel-dri3.conf
Section "Device"
	Identifier  "intel0"
	Driver      "intel"
	Option      "DRI" "3"
EndSection

Xorg.0.log:
intel(0): direct rendering: DRI2 DRI3 enabled
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

GL/DRI3 over ssh broken
https://bugs.freedesktop.org/show_bug.cgi?id=93261

Resolved in xserver.

Created attachment 1122503 [details]
Fix DRI3 over ssh

Reported-by: Michael Stahl <mstahl>
Suggested-by: Daniel Stone <daniel>
Tested-by: poma <pomidorabelisima>

$ rpm --query --changelog xorg-x11-server-Xorg-1.18.1-2.fc22.x86_64
* Tue Feb 09 2016 poma <poma> 1.18.1-2
- dri3: Refuse to work for remote clients (v2)

* Mon Feb 08 2016 Adam Jackson <ajax> 1.18.1-1
- xserver 1.18.1

* Mon Jan 04 2016 poma <poma> 1.18.0-5
- os: Treat ssh as a non-local client (v3)

* Fri Dec 11 2015 poma <poma> 1.18.0-4
- dri3: Refuse to work for remote clients

* Fri Dec 11 2015 poma <poma> 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:
   xorg-x11-server-Xorg-1.18.3-2.fc23.x86_64

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 5.0.6.2 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 5.0.6.2 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 5.0.6.2-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
https://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.18-branch&id=3c4cead

xorg-x11-server-1.18.4-1.fc24
https://bodhi.fedoraproject.org/updates/FEDORA-2016-a0ad95d1d7

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'
of '23'.

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
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.