First, steps to reproduce:

1. Run:

 socat UNIX-LISTEN:/tmp/.X11-unix/X1,fork UNIX-CONNECT:/tmp/.X11-unix/X0

2. Run:

 DISPLAY=:1 glxgears

Expected behaviour:

glxgears works as expected.

Actual behaviour:

glxgears hangs at startup.

The system I can reproduce this problem on is a Sony Vaio SVS15123CXB laptop with a Core i5-3210M and "Intel Corporation 3rd Gen Core processor Graphics Controller", running Arch Linux with Linux 4.11.9-1-ARCH, mesa 17.1.5-1 and libxcb 1.12-1.

glxgears runs fine through socat on my desktop machine with an NVIDIA card.

Stack trace of hanging glxgears:

#0  0x00007fb5d9103e80 in __poll_nocancel () from /usr/lib/libc.so.6
#1  0x00007fb5d82e7857 in poll (__timeout=-1, __nfds=1, __fds=0x7ffe40792438) at /usr/include/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0x55a1e2187030, cond=cond@entry=0x7ffe40792550, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:479
#3  0x00007fb5d82e933f in wait_for_reply (c=c@entry=0x55a1e2187030, request=26, e=e@entry=0x0) at xcb_in.c:516
#4  0x00007fb5d82e9450 in xcb_wait_for_reply (c=c@entry=0x55a1e2187030, request=26, e=e@entry=0x0) at xcb_in.c:546
#5  0x00007fb5d7828005 in xcb_dri3_open_reply (c=c@entry=0x55a1e2187030, cookie=..., e=e@entry=0x0) at dri3.c:146
#6  0x00007fb5d7cacaca in loader_dri3_open (conn=conn@entry=0x55a1e2187030, root=<optimized out>, provider=provider@entry=0) at loader_dri3_helper.c:779
#7  0x00007fb5d7ca6eb0 in dri3_create_screen (screen=0, priv=0x55a1e2197d20) at dri3_glx.c:801
#8  0x00007fb5d7c7b2a6 in AllocAndFetchScreenConfigs (priv=0x55a1e2197d20, dpy=0x55a1e2185d00) at glxext.c:806
#9  __glXInitialize (dpy=dpy@entry=0x55a1e2185d00) at glxext.c:932
#10 0x00007fb5d7c76a44 in GetGLXPrivScreenConfig (dpy=dpy@entry=0x55a1e2185d00, scrn=scrn@entry=0, ppriv=ppriv@entry=0x7ffe40792710, ppsc=ppsc@entry=0x7ffe40792718) at glxcmds.c:173
#11 0x00007fb5d7c77905 in glXChooseVisual (dpy=0x55a1e2185d00, screen=0, attribList=0x7ffe40792970) at glxcmds.c:1246
#12 0x000055a1e149359b in make_window (dpy=0x55a1e2185d00, x=0, y=0, width=300, height=300, winRet=0x7ffe40792af0, ctxRet=0x7ffe40792af8, visRet=0x7ffe40792b00, name=0x55a1e1493b1f "glxgears") at glxgears.c:520
#13 0x000055a1e1491a97 in main (argc=<optimized out>, argv=<optimized out>) at glxgears.c:777

My wild guess is that something in mesa or xcb is treating the X11 connection as datagram-oriented, instead of stream-oriented, and either discards additional data that was received in one recv call, or does not keep trying to read more data if not enough data was received in one recv call.