libX11: Changes to 'master'

[Aaron Plattner]

 src/XlibInt.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

New commits:
commit 2d20890e7ffd3ee88a9ceb25cdd2ac1fe7aaceb6
Author: Arthur Huillet <ahuillet at nvidia.com>
Date:   Wed Feb 1 15:02:41 2017 +0100

    _XDefaultError: set XlibDisplayIOError flag before calling exit
    
    _XReply isn't reentrant, and it can lead to deadlocks when the default error
    handler is called: _XDefaultError calls exit(1). It is called indirectly by
    _XReply when a X protocol error comes in that isn't filtered/handled by an
    extension or the application. This means that if the application (or one of its
    loaded shared libraries such as the NVIDIA OpenGL driver) has registered any
    _fini destructor, _fini will get called while still on the call stack of
    _XReply. If the destructor interacts with the X server and calls _XReply, it
    will hit a deadlock, looping on the following in _XReply:
    
        ConditionWait(dpy, dpy->xcb->reply_notify);
    
    It is legal for an application to make Xlib calls during _fini, and that is
    useful for an OpenGL driver to avoid resource leaks on the X server side, for
    example in the dlopen/dlclose case. However, the driver can not readily tell
    whether its _fini is being called because Xlib called exit, or for another
    reason (dlclose), so it is hard to cleanly work around this issue in the driver.
    
    This change makes it so _XReply effectively becomes a no-op when called after
    _XDefaultError was called, as though an XIOError had happened. The dpy
    connection isn't broken at that point, but any call to _XReply is going to hang.
    This is a bit of a kludge, because the more correct solution would be to make
    _XReply reentrant, maybe by broadcasting the reply_notify condition before
    calling the default error handler. However, such a change would carry a grater
    risk of introducing regressions in Xlib.
    
    This change will drop some valid requests on the floor, but this should not
    matter, as it will only do so in the case where the application is dying: X will
    clean up after it once exit() is done running. There is the case of
    XSetCloseDownMode(RETAIN_PERMANENT), but an application using that and wishing
    to clean up resources in _fini would currently be hitting a deadlock, which is
    hardly a better situation.
    
    Signed-off-by: Aaron Plattner <aplattner at nvidia.com>
    Reviewed-by: Jamey Sharp <jamey at minilop.net>