I've been seeing sporadic (anywhere from once every few days to 3-4
times a day) crashes and freezes in X. The problematic behaviour isn't
always the same, but I chose a particular incident to debug, and found
that X was segfaulting in updateMotionHistory, on line 575 of
dix/getevents.c.
After some further investigation, I found that the bug was being
triggered when a SIGIO was received in DeepCopyPointerClasses, between
the AllocValuatorClass call (line 540) and updating the to->valuator
pointer (line 545). AllocValuatorClass calls realloc() on to->valuator,
so between these lines, it's not guaranteed to point to allocated
memory.
It seems the SIGIO handler is calling updateMotionHistory, which is
reading the memory pointed to by to->valuator and getting a wrong value
for last_motion, which updates buff to point to wildly the wrong place
and thus generates a segfault when a memcpy() is done into buff.
I am attaching a patch which I've been running on that machine for the
past three days, and haven't yet observed any more crashing or freezing
behaviour. The patch simply calls OsBlockSIGIO while
DeepCopyDeviceClasses is in progress, as the state of the X server's
device data structures is not guaranteed to be in a consistent state
during that time.
Debian bug#744303 <https://bugs.debian.org/744303>
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit d7a2df0a74)
The easiest way to check for the version of an extension is to send the maximum
possible version numbers in the QueryVersion request. The X server overflows on
these as it assumes you will send a reasonable version number.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 548fc937b2)
DontZap off is the default anyway, don't mention it specifically to avoid
confusion
X.Org Bug 71113 <http://bugs.freedesktop.org/show_bug.cgi?id=71113>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit cfaf2abbac)
The visualSelectGroup wasn't getting set (since our DRI drivers don't
use it), and and since it's the top priority in the sort order, you
got random sorting of your visuals unless malloc really returned you
new memory. This manifested as Xephyr -glamor rendering to a
multisampled window on my system, which as you might guess was
slightly lower performance than expected.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
The XResizeWindow call wasn't replaced by the xcb equivalent, so we
were no longer setting the initial window size, only wm size hints.
Regression from commit a2b73da "Xephyr: start converting hostx.c over to
xcb"
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74849
Signed-off-by: Julien Cristau <jcristau@debian.org>
Reported-by: Laércio de Sousa <lbsousajr@gmail.com>
Tested-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
The PnPID for a device may not be on the immediate parent, so search up the
device tree until we find one.
X.Org Bug 75513 <http://bugs.freedesktop.org/show_bug.cgi?id=75513>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
(cherry picked from commit 795066477e)
The other values are checked correctly, but if a modifier was outside the
allowed range, it would go unnoticed and cause a out-of-bounds read error for
any mask equal or larger than 256. The DetailRec where we store the grab masks
is only sized to 8 * sizeof(Mask).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 0f10cfd4b9)
On OpenBSD, passing a timeout longer than 100000000 seconds to select(2) will
make it fail with EINVAL. As this is original 4.4BSD behaviour it is not
inconceivable that other systems suffer from the same problem. And Linux,
though not suffering from any 4.4BSD heritage, briefly did something similar:
<https://lkml.org/lkml/2012/8/31/263>
So avoid calling AdjustWaitForDelay() instead of setting the timeout to
(effectively) ULONG_MAX milliseconds.
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
(cherry picked from commit ddeca92749)
The server internally relies on arrays with a MAX_BUTTONS maximum size (which
is the max the core protocol can transport). Make sure a driver adheres to
that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
(cherry picked from commit 87ca80a719)
Flagged by cppcheck 1.62:
[hw/xfree86/common/xf86Helper.c:220] -> [hw/xfree86/common/xf86Helper.c:231]:
(warning) Possible null pointer dereference: pScrn - otherwise it is
redundant to check it against null.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit c1ac89c793)
Flagged by cppcheck 1.62:
[dix/dixfonts.c:1792]: (error) Common realloc mistake:
'font_path_string' nulled but not freed upon failure
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit e6733ae91b)
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit 9fc19168e7)
The request is followed by mask_len 4-byte units, then followed by the actual
modifiers.
Also fix up the swapping test, which had the same issue.
Reported-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
(cherry picked from commit 76b3be75b6)
Conflicts:
test/xi2/protocol-xipassivegrabdevice.c
We call atoi() on the server's display to get the socket but otherwise use the
unmodified display for log file name, xkb paths, etc. This results in
Xorg :banana being the equivalent of Xorg :0, except for the log files being
in /var/log/Xorg.banana.log. I'm not sure there's a good use-case for this
behaviour.
Check the display for something that looks reasonable, i.e. digits only, but
do allow for :0.0 (i.e. digits, followed by a period, followed by one or two
digits).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
(cherry picked from commit 71baa466b1)
When a grab on a slave device is deactivated, the master device must
be checked, just in case there were events from other devices while
the slave device was stolen away by the passive grab. This may
introduce misbehaviors on mismatching valuators and device features
later on UpdateDeviceState().
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
(cherry picked from commit b2d5ee2e36)
dev->button->down is a bitmask, not a normal array. Use the helper function to
check, we technically allow the mapping to change after the physical button
has been pressed (but not yet processed yet), so only check BUTTON_PROCESSED.
From XSetPointerMapping(3):
"If any of the buttons to be altered are logically in the down state,
XSetPointerMapping returns MappingBusy, and the mapping is not changed."
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
(cherry picked from commit 25d10464f4)
It seems the alanyzer can't comprehend dixSetPrivate().
quartz.c:119:12: warning: Potential leak of memory pointed to by 'displayInfo'
return quartzProcs->AddScreen(index, pScreen);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit 64327226dd)
Avoids potential memory corruption from bad requests
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit a03f096a85)
Return an error to the caller rather than crashing the server on
invalid screens.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit b3572c0d1a)
x-hook.c:96:9: warning: Called function pointer is an uninitalized pointer value
(*fun[i])(arg, data[i]);
^~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit 959e8f23af)
X11Controller.m:938:1: warning: method 'applicationWillTerminate:' could be declared with attribute 'noreturn'
[-Wmissing-noreturn,Semantic Issue]
{
^
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit f79af19417)
./darwinfb.h:28:9: warning: '_DARWIN_FB_H' is used as a header guard here, followed by #define of a different macro
[-Wheader-guard,Lexical or Preprocessor Issue]
^~~~~~~~~~~~
./darwinfb.h:29:9: note: '_DARWIN_DB_H' is defined here; did you mean '_DARWIN_FB_H'? [Lexical or Preprocessor Issue]
^~~~~~~~~~~~
_DARWIN_FB_H
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
(cherry picked from commit 2e3ebec952)
Skipped present pixmap calls were not setting the mode to
PresentCompleteModeSkip for skipped operations.
Signed-off-by: Keith Packard <keithp@keithp.com>
Presents which are not marked 'queued' and are in the window present
list are waiting for the flip event; discarding those won't work very
well (it'll end up trashing displayed content for the next frame), so
skip over those when looking for duplicate frame presents
Signed-off-by: Keith Packard <keithp@keithp.com>
Check for Async flag and execute immediately if set, otherwise wait
for the next appropriate vblank before copying.
Signed-off-by: Keith Packard <keithp@keithp.com>
This can't happen when GLX is the backing window system, but can
elsewhere. We may as well protect against it at a high level.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We want to advertise the version we implement, not the version the
protocol headers happen to describe.
Reviewed-by: Jasper St. Pierre <<jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
We want to advertise the version we implement, not the version the
protocol headers happen to describe.
Reviewed-by: Jasper St. Pierre <<jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
There's nothing to stop a client from sending these requests to screens
without DRI3 support, and if they do, we'll crash. Let's not do that.
Reviewed-by: Jasper St. Pierre <<jstpierre@mecheye.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Peter Hutterer
Steven McDonald
Robert Ancell
Matt Dew
Jeremy Huddleston Sequoia
Peter Harris
Eric Anholt
Julien Cristau
Mark Kettenis
Alan Coopersmith
Carlos Garnacho
Keith Packard
Adam Jackson