Skip to content

N
nx-libs
Switch branch/tag
  1. 03 Apr, 2017 1 commit
  3. 30 Mar, 2017 1 commit
  5. 29 Mar, 2017 1 commit
  7. 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
      Merge branch 'sunweaver-pr/dix-dispatch-backports' into 3.6.x · ac03b517
      Mihai Moldovan authored 
      Attributes GH PR #412: https://github.com/ArcticaProject/nx-libs/pull/412
      ac03b517
  11. 24 Mar, 2017 3 commits
  13. 21 Mar, 2017 24 commits
  15. 20 Mar, 2017 5 commits
    • Adam Jackson's avatar
      Don't crash on unconfigured interfaces. (X.org bug #5218, Andrei Barbu) · eac0a8fa
      Adam Jackson authored 
       commit 9d62d1e6903ccc095f784279a699b3f40a8f0cf8
 Author: Adam Jackson <ajax@nwnk.net>
 Date:   Sat Jan 7 00:45:17 2006 +0000

    Bug #5218: Don't crash on unconfigured interfaces. (Andrei Barbu)
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      eac0a8fa
    • Alan Coopersmith's avatar
      Set padding bytes to 0 in WriteToClient · f9123570
      Alan Coopersmith authored 
       commit bed610fcae41ddfe21fa9acde599b17d1d15f5d1
 Author: Alan Coopersmith <alan.coopersmith@oracle.com>
 Date:   Mon Jul 9 19:12:44 2012 -0700

    Set padding bytes to 0 in WriteToClient

    Clear them out when needed instead of leaving whatever values were
    present in previously sent messages.
Signed-off-by: 's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
Tested-by: 's avatarDaniel Stone <daniel@fooishbar.org>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      f9123570
    • Aaron Plattner's avatar
      os: Return BadLength instead of disconnecting BigReq clients (#4565) · 2ecd2a00
      Aaron Plattner authored 
       Backported from X.org:

 commit 67c66606c760c263d7a4c2d1bba43ed6225a4e7c
 Author: Robert Morell <rmorell@nvidia.com>
 Date:   Thu May 9 13:09:02 2013 -0700

    os: Reset input buffer's 'ignoreBytes' field

    If a client sends a request larger than maxBigRequestSize, the server is
    supposed to ignore it.

    Before commit cf88363d, the server would simply disconnect the client.  After
    that commit, it attempts to gracefully ignore the request by remembering how
    long the client specified the request to be, and ignoring that many bytes.
    However, if a client sends a BigReq header with a large size and disconnects
    before actually sending the rest of the specified request, the server will
    reuse the ConnectionInput buffer without resetting the ignoreBytes field.  This
    makes the server ignore new X clients' requests.

    This fixes that behavior by resetting the ignoreBytes field when putting the
    ConnectionInput buffer back on the FreeInputs list.
Signed-off-by: 's avatarRobert Morell <rmorell@nvidia.com>
Reviewed-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: 's avatarPeter Hutterer <peter.hutterer@who-t.net>

 commit c80c41767eb101e9dbd8393d8cca7764b4e248a4
 Author: Aaron Plattner <aplattner@nvidia.com>
 Date:   Mon Oct 25 22:01:32 2010 -0700

    os: Fix BigReq ignoring when another request is pending

    Commit cf88363db0ebb42df7cc286b85d30d7898aea840 fixed the handling of
    BigReq requests that are way too large and handles the case where the
    read() syscall returns a short read.  However, it neglected to handle
    the case where it returns a long read, which happens when the client
    has another request in the queue after the bogus large one.

    Handle the long read case by subtracting the smaller of 'needed' and
    'gotnow' from oci->ignoreBytes.  If needed < gotnow, simply subtract
    the two, leaving gotnow equal to the number of extra bytes read.
    Since the code immediately following the (oci->ignoreBytes > 0) block
    tries to handle the next request, advance oci->bufptr immediately
    instead of setting oci->lenLastReq and letting the next call to
    ReadRequestFromClient do it.

    Fixes the XTS pChangeKeyboardMapping-3 test.

             CASES TESTS  PASS UNSUP UNTST NOTIU  WARN   FIP  FAIL UNRES  UNIN ABORT
    -Xproto    122   389   367     2    19     0     0     0     1     0     0     0
    +Xproto    122   389   368     2    19     0     0     0     0     0     0     0
Signed-off-by: 's avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: 's avatarAdam Jackson <ajax@redhat.com>
Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>

 commit cf88363db0ebb42df7cc286b85d30d7898aea840
 Author: Aaron Plattner <aplattner@nvidia.com>
 Date:   Fri Aug 27 10:20:29 2010 -0700

    os: Return BadLength instead of disconnecting BigReq clients (#4565)

    If a client sends a big request that's too big (i.e. bigger than
    maxBigRequestSize << 2 bytes), the server just disconnects it.  This makes the
    client receive SIGPIPE the next time it tries to send something.

    The X Test Suite sends requests that are too big when the test specifies the
    TOO_LONG test type.  When the client receives SIGPIPE, XTS marks it as
    UNRESOLVED, which counts as a failure.

    Instead, remember how long the request is supposed to be and then return that
    size.  Dispatch() checks the length and sends BadLength to the client.  Then,
    whenever oci->ignoreBytes is nonzero, ignore the data read instead of trying to
    process it as a request.
Signed-off-by: 's avatarAaron Plattner <aplattner@nvidia.com>
Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      2ecd2a00
    • Peter Harris's avatar
      Fix overflow of ConnectionOutput->size and ->count · cbc2d300
      Peter Harris authored 
       commit 4b0d0df34f10a88c10cb23dd50087b59f5c4fece
 Author: Peter Harris <pharris@opentext.com>
 Date:   Mon Nov 17 14:31:24 2014 -0500

    Fix overflow of ConnectionOutput->size and ->count

    When (long) is larger than (int), and when realloc succeeds with sizes
    larger than INT_MAX, ConnectionOutput->size and ConnectionOutput->count
    overflow and become negative.

    When ConnectionOutput->count is negative, InsertIOV does not actually
    insert an IOV, and FlushClient goes into an infinite loop of writev(fd,
    iov, 0) [an empty list].

    Avoid this situation by killing the client when it has more than INT_MAX
    unread bytes of data.
Signed-off-by: 's avatarPeter Harris <pharris@opentext.com>
Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
Signed-off-by: 's avatarKeith Packard <keithp@keithp.com>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      cbc2d300
    • Michel Dänzer's avatar
      dix: Pass ClientPtr to FlushCallback · 65b6a62b
      Michel Dänzer authored 
       Backported X.org commits:

 commit b380f3ac51f40ffefcde7d3db5c4c149f274246d
 Author: Michel Dänzer <michel.daenzer@amd.com>
 Date:   Tue Aug 2 17:53:01 2016 +0900

    dix: Pass ClientPtr to FlushCallback

    This change has two effects:

    1. Only calls FlushCallbacks when we're actually flushing data to a
       client. The unnecessary FlushCallback calls could cause significant
       performance degradation with compositing, which is significantly
       reduced even without any driver changes.

    2. By passing the ClientPtr to FlushCallbacks, drivers can completely
       eliminate unnecessary flushing of GPU commands by keeping track of
       whether we're flushing any XDamageNotify events to the client for
       which the corresponding rendering commands haven't been flushed to
       the GPU yet.
Reviewed-by: 's avatarAdam Jackson <ajax@redha.com>
Signed-off-by: 's avatarMichel Dänzer <michel.daenzer@amd.com>

 commit c65f610e12f9df168d5639534ed3c2bd40afffc8
 Author: Kristian Høgsberg <krh@bitplanet.net>
 Date:   Thu Jul 29 18:52:35 2010 -0400

    Always call the flush callback chain when we flush client buffers

    We were missing the callback in a couple of places.  Drivers may use
    the flush callback to submit batched up rendering before events (for
    example, damage events) are sent out, to ensure that the rendering
    has been queued when the client receives the event.
Signed-off-by: 's avatarKristian Høgsberg <krh@bitplanet.net>
Reviewed-by: 's avatarKeith Packard <keithp@keithp.com>
Backported-to-NX-by: 's avatarMike Gabriel <mike.gabriel@das-netzwerkteam.de>
      65b6a62b