XCopyColormapAndFree/5 threw an assertion:
520|4 5 00014017 1 2|Assertion XCopyColormapAndFree-5.(A)
520|4 5 00014017 1 3|When a colourmap argument does not name a valid colourmap,
520|4 5 00014017 1 4|then a BadColor error occurs.
520|4 5 00014017 1 5|METH: Create a bad colourmap by creating and freeing a colourmap.
520|4 5 00014017 1 6|METH: Call test function using bad colourmap as the colourmap argument.
520|4 5 00014017 1 7|METH: Verify that a BadColor error occurs.
520|4 5 00014017 1 8|unexpected signal 6 (SIGABRT) received
220|4 5 2 15:05:53|UNRESOLVED
410|4 5 1 15:05:53|IC End
510|4|system 0: Abandoning testset: caught unexpected signal 11 (SIGSEGV)
More specifically:
lt-XCopyColormapAndFree: xcb_io.c:533: _XAllocID: Assertion `ret != inval_id' failed.
This bug was introduced (by following my advice, d'oh) in:
commit 99a2cf1aa0
Author: Tapani Pälli <tapani.palli@intel.com>
Date: Mon May 13 08:29:49 2019 +0300
Protect colormap add/removal with display lock
In that patch we moved the call to _XcmsCopyCmapRecAndFree inside the
display lock. The problem is said routine has side effects, including
trying to implicitly create a colormap in some cases. Since we don't run
the XID handler until SyncHandle() we would see inconsistent internal
xlib state, triggering the above assert.
Fix this by dropping and re-taking the display lock before calling into
XCMS.
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
lowercase: GREEK SMALL LETTER FINAL SIGMA (U+03C2)
uppercase: GREEK CAPITAL LETTER SIGMA (U+03A3)
This mapping was correct in UCSConvertCase, but the "legacy" mapping
must also be correct for Caps Lock to work with the final sigma key.
https://gitlab.freedesktop.org/xorg/lib/libx11/issues/5
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com>
lowercase: LATIN SMALL LETTER SHARP S (U+00DF)
uppercase: LATIN CAPITAL LETTER SHARP S (U+1E9E)
The uppercase sharp s (XK_ssharp) is a relatively recent addition to unicode
but was added to the relevant keyboard layouts in xkeyboard-config-2.25
(d1411e5e95c)
https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/issues/144
Alas, the CapsLock behavior was broken on the finnish layout (maybe others).
This was due to xkbcomp using XConvertCase() to determine whether a key
requires the type FOUR_LEVEL_ALPHABETIC or FOUR_LEVEL_SEMIALPHABETIC.
Let's make this function return the right lower/upper symbols for the sharp s
and hope that the world won't get any worse because of it.
https://gitlab.freedesktop.org/xorg/lib/libx11/issues/110
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch is based on a suggestion made by Uli Schlachter in a comment
to the bug report https://gitlab.freedesktop.org/xorg/lib/libx11/issues/93.
Explanation of the bug (given by Uli Schlachter as well):
An error was received and handled. Since there was an error callback set,
Xlib unlocks the display, runs the error callback, and then locks the display
again. This goes through _XLockDisplay and then calls _XSeqSyncFunction.
On this "lock the thing"-path, Xlib notices that sequence numbers are close to
wrap-around and tries to send a GetInputFocus request. However, the earlier
calls already registered themselves as "we are handling replies/errors, do
not interfere!" and so the code here waits for "that other thread" to be done
before it continues. Only that there is no other thread, but it is this thread
itself and thus a deadlock follows.
The bug is relatively easy to reproduce on any desktop environment by
using actively a touchscreen input that supports multitouch, i.e. practically
all mobile devices are affected.
Fixes: https://gitlab.freedesktop.org/xorg/lib/libx11/issues/93
Suggested-by: Uli Schlachter <psychon@znc.in>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Simply looking at libtool redefines LINK globally to use libtool, which when
you're trying to cross-compile to Windows can cause complications.
As in src/util/ we're simply building a small binary for the build host, reset
LINK to the automake default so that the traditional compile/link steps occur
without libtool.
Also remove -all-static from LDFLAGS as that is a libtool-specific argument
intended to solve this problem.
Closes: #100
Signed-off-by: Ross Burton <ross.burton@intel.com>
to remove the fake quotes replace them with propper
predefined macros \*(lq and \*(rq. this will allow
nroff to choose the propper characters when using ps etc.
Signed-off-by: Walter Harms <wharms@bfs.de>
after converting everything to st. man page macros there is
no need to maintain X11 private nroff macros, so remove them.
Signed-off-by: Walter Harms <wharms@bfs.de>
Same pages use the man page .EX/.EE macro. Replace all occurences
of .De/.Ds with the std. macros to make the code better to maintain.
Signed-off-by: Walter Harms <wharms@bfs.de>
Replace the home grown macro .ZN with std. macros
from man macro paket. So we can get rid of the
definition an get a clean header.
Signed-off-by: Walter Harms <wharms@bfs.de>
Subsequent to a121b7b0c2 we are no longer
building makekeys with enough -I/foo/bar to find the X11 headers, so if
they're not in a system include path, things fail. Since this utility is
only needed at build time, there's no real reason to demand the X
headers be installed for both the build and target machines if cross-
compiling, we can just assume a vaguely ANSI environment instead.
Tested-by: Niclas Zeising <zeising@daemonic.se>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
... and include config.h in makekeys.c to get the definition of
_FILE_OFFSET_BITS. Without it, libX11 can fail to build on a file
system with 64-bit inode numbers.
Bug: https://bugs.gentoo.org/550502
Bug: https://bugs.gentoo.org/616140
Signed-off-by: Matt Turner <mattst88@gmail.com>
The man page says:
Strings may be direct text encoded in the locale for which the
compose file is to be used, or an escaped octal or hexadecimal
character code. Octal codes are specified as "\123" and
hexadecimal codes as "\0x123a".
But the grammar in the parser and the implementation say:
ESCAPED_CHAR ::= ('\\' | '\"' | OCTAL | HEX )
HEX ::= '\' (x|X) HEX_CHAR [HEX_CHAR]]
HEX_CHAR ::= (0|1|2|3|4|5|6|7|8|9|A|B|C|D|E|F|a|b|c|d|e|f)
So "\0x123a" -> "\x3a".
Signed-off-by: Ran Benita <ran234@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
a simple snippet like XFreeFontSet(d, XCreateFontSet(d, ...)) will generate lots of memory leaks,
as evidenced by the following valgrind output:
==983== HEAP SUMMARY:
==983== in use at exit: 39,409 bytes in 341 blocks
==983== total heap usage: 4,795 allocs, 4,454 frees, 489,086 bytes allocated
==983==
==983== 1,688 (136 direct, 1,552 indirect) bytes in 1 blocks are definitely lost in loss record
40 of 46
==983== at 0x4C2B042: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==983== by 0x56D5A93: add_codeset.clone.9 (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56D5FE0: load_generic (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56D7612: initialize (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56D7E75: _XlcCreateLC (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56F9A5F: _XlcUtf8Loader (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56DF815: _XOpenLC (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56B255A: XOpenOM (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x56A665A: XCreateFontSet (in /usr/lib64/libX11.so.6.3.0)
==983== by 0x4FCA80: conky::x11_output::create_gc() (x11.cc:746)
==983== by 0x4FC3B4: conky::x11_output::use_own_window() (x11.cc:602)
==983== by 0x4FAD42: conky::priv::own_window_setting::set(bool const&, bool) (x11.cc:92)
==983==
==983== LEAK SUMMARY:
==983== definitely lost: 136 bytes in 1 blocks
==983== indirectly lost: 1,552 bytes in 34 blocks
==983== possibly lost: 0 bytes in 0 blocks
==983== still reachable: 37,721 bytes in 306 blocks
==983== suppressed: 0 bytes in 0 blocks
This patch makes the leak dissappear (Well, at least the "definitely lost part". The "still
reachable" thingy remains). After some analysis, I've discovered that the XLCd structure is
destroyed improperly. The "constructor" is in lcGeneric.c, but the structure is destroyed using
code from lcPublic.c. I've found that changing the destructor call to _XlcDestroyLC executes the
correct code path, and I'm pretty sure this is correct (the object was constructed using
_XlcCreateLC, it make sense to destroy it using its conterpart).
So far I haven't observed any strange behaviour on my system caused by this change (although, I'm
not sure, how many programs actually use this function).
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
For Windows targets, libtool uses a wrapper executable, not a wrapper
script (see [1]), which it compiles with the host compiler. This
doesn't work when cross-compiling.
Since we don't actually need to link with anything, use the libtool flag
-all-static to tell it to stay completely out of this.
[1] https://www.gnu.org/software/libtool/manual/html_node/Wrapper-executables.html
Use EXEXT_FOR_BUILD, to fix cross-compiling where EXEEXT differs from
EXEEXT_FOR_BUILD, such as when building for Windows from unix.
(Note: As written, this assumes EXEEXT_FOR_BUILD is always empty when
cross-compiling. There could be some elaborate autodetection for
EXEXT_FOR_BUILD, but for the moment, if you are cross-compiling from
Windows to Unix, you'll need to set EXEEXT_FOR_BUILD explicity...)
This is the patch from https://bugs.freedesktop.org/show_bug.cgi?id=6669
by Pierre Ossman, reworked for master.
Avoid using LIBS (which are for host, but we don't need) and rewrite
makekeys slightly to avoid needing to include any X headers, which
avoids potentially having -I with host paths in CFLAGS, which can cause
standard headers e.g. stdio.h for the host to also be used, which can
break things...
On finishing releasing Braille keys, we should clear the just-commited
pattern, to reset the state to initial state, and avoid having to wait for
0.3s before typing the next pattern.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: Jean-Philippe Mengual <jpmengual@hypra.fr>
This fixes a bug where concurrent threads call XCreateColormap and
XFreeColormap corrupting a linked list where colormap structures
are stored.
Fixes: https://gitlab.freedesktop.org/xorg/lib/libx11/issues/94
v2: handle XCopyColormapAndFree also (Adam Jackson)
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Currently, when the X server crashes or a client is disconnected with
XKillClient, you get a somewhat confusing error message from libX11
along the lines of:
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 98 requests (40 known processed) with 0 events remaining.
What's happening here is the previous recvmsg has thrown EAGAIN, since
the socket is non-blocking. In this case, check whether the socket has
any more data to read, and if not treat it like EPIPE.
Signed-off-by: Adam Jackson <ajax@redhat.com>
