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>
In-tree builds found reallocarray.h in $(top_builddir)/src but the
out-of-tree build didn't find it at all.
Reported-by: Emmanuele Bassi <ebassi@gmail.com> from GNOME continuous integration pipeline
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Makes resizing & clearing more consistent and gets rid of some weird
quirks like always subtracting 1 from the size passed to _XkbClearElems
so it could always add 1 to the size passed in.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Wrapper for realloc() that checks for overflow when multiplying
arguments together, so we don't have to add overflow checks to
every single call. For documentation on usage, see:
http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/calloc.3
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
It avoids reading from the display connection again in cases where that
was already done.
Suggested-by: Uli Schlachter <psychon@znc.in>
Reviewed-by: Uli Schlachter <psychon@znc.in>
If xcb_poll_for_reply fails to find a reply, poll_for_response would
always return NULL. However, xcb_poll_for_reply may have read events
from the display connection while looking for a reply. In that case,
returning NULL from poll_for_response is wrong and can result in the
client hanging, e.g. because it returns to waiting for the display
connection file descriptor becoming readable after XPending incorrectly
returned 0 pending events.
The solution is to call poll_for_event again after xcb_poll_for_reply
returned 0. This will return the first of any events read by
xcb_poll_for_reply.
Fixes issue #79.
Reported-by: Yuxuan Shui <yshuiv7@gmail.com>
Bugzilla: https://bugs.freedesktop.org/108008
Bugzilla: https://bugs.freedesktop.org/107992
Reviewed-by: Adam Jackson <ajax@redhat.com>
If the server sends a reply in which even the first string would
overflow the transmitted bytes, list[0] (or flist[0]) will be set to
NULL and a count of 0 is returned.
If the resulting list is freed with XFreeExtensionList or
XFreeFontPath later on, the first Xfree call:
Xfree (list[0]-1)
turns into
Xfree (NULL-1)
which will most likely trigger a segmentation fault.
I have modified the code to return NULL if the first string would
overflow, thus protecting the freeing functions later on.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
The length value is interpreted as signed char on many systems
(depending on default signedness of char), which can lead to an out of
boundary write up to 128 bytes in front of the allocated storage, but
limited to NUL byte(s).
Casting the length value to unsigned char fixes the problem and allows
string values with up to 255 characters.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
The functions XGetFontPath, XListExtensions, and XListFonts are
vulnerable to an off-by-one override on malicious server responses.
The server replies consist of chunks consisting of a length byte
followed by actual string, which is not NUL-terminated.
While parsing the response, the length byte is overridden with '\0',
thus the memory area can be used as storage of C strings later on. To
be able to NUL-terminate the last string, the buffer is reserved with
an additional byte of space.
For a boundary check, the variable chend (end of ch) was introduced,
pointing at the end of the buffer which ch initially points to.
Unfortunately there is a difference in handling "the end of ch".
While chend points at the first byte that must not be written to,
the for-loop uses chend as the last byte that can be written to.
Therefore, an off-by-one can occur.
I have refactored the code so chend actually points to the last byte
that can be written to without an out of boundary access. As it is not
possible to achieve "ch + length < chend" and "ch + length + 1 > chend"
with the corrected chend meaning, I removed the inner if-check.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
