1. 10 Apr, 2017 1 commit
  2. 07 Apr, 2017 4 commits
  3. 06 Apr, 2017 3 commits
  4. 05 Apr, 2017 2 commits
  5. 03 Apr, 2017 21 commits
  6. 30 Mar, 2017 1 commit
  7. 29 Mar, 2017 1 commit
  8. 27 Mar, 2017 2 commits
  9. 26 Mar, 2017 3 commits
    • Arthur Huillet's avatar
      _XDefaultError: set XlibDisplayIOError flag before calling exit · 00405b27
      Arthur Huillet authored
      _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: 's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: 's avatarJamey Sharp <jamey@minilop.net>
      00405b27
    • Julien Cristau's avatar
      Fix wrong Xfree in XListFonts failure path · 8ad49a03
      Julien Cristau authored
      'ch' gets moved inside the allocated buffer as we're looping through
      fonts, so keep a reference to the start of the buffer so we can pass
      that to Xfree in the failure case.
      
      Fixes: commit 20a3f99eba5001925b8b313da3accb7900eb1927 "Plug a memory leak"
      Signed-off-by: 's avatarJulien Cristau <jcristau@debian.org>
      Reviewed-by: 's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
      8ad49a03
    • Mihai Moldovan's avatar
  10. 24 Mar, 2017 2 commits