Fix wrong Xfree in XListFonts failure path

'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: Julien Cristau <[email protected]>
Reviewed-by: Alan Coopersmith <[email protected]>
Signed-off-by: Peter Hutterer <[email protected]>

_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 <[email protected]>
Reviewed-by: Jamey Sharp <[email protected]>

Release 3.5.99.4

Release 3.5.99.3

Release 3.5.99.2

Validation of server responses in XGetImage()

Check if enough bytes were received for specified image type and
geometry. Otherwise GetPixel and other functions could trigger an
out of boundary read later on.

Signed-off-by: Tobias Stoeckmann <[email protected]>
Reviewed-by: Matthieu Herrb <[email protected]>

compose: fix the description of modifiers in compose sequences

The Compose format has a feature which allows specifying certain
modifiers must (or must not) be present with a given keysym in the
sequence.

The grammar in imLcPrs.c and the Compose man page both do not match what
the code actually does (see the handling of the variables
`modifier_mask` and `modifier` in parseline() in imLcPrs.c, which are
eventually matched as `ev->state & modifier_mask == modifier`).

Also explicitly list the accepted modifier names, since they are
not standard (e.g. "Ctrl" instead of "Control").

Signed-off-by: Ran Benita <[email protected]>
Signed-off-by: James Cloos <[email protected]>

Bug 68413 - [Bisected]Error in `xterm': realloc(): invalid next size

Pass *new* size to realloc, not old size.

Signed-off-by: Alan Coopersmith <[email protected]>

omGeneric: remove space between struct name & member name

Signed-off-by: Alan Coopersmith <[email protected]>

update Xfuncproto.h