Reordered code to first to do the comparison and then to release data
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
If we receive unsupported event closing connection triggers valgrind
error.
==12017== Conditional jump or move depends on uninitialised value(s)
==12017== at 0x487D454: _XFreeDisplayStructure (OpenDis.c:607)
==12017== by 0x486857B: XCloseDisplay (ClDisplay.c:72)
*snip*
==12017== Uninitialised value was created by a heap allocation
==12017== at 0x4834C48: malloc (vg_replace_malloc.c:236)
==12017== by 0x4894147: _XEnq (XlibInt.c:877)
==12017== by 0x4891BF3: handle_response (xcb_io.c:335)
==12017== by 0x4892263: _XReply (xcb_io.c:626)
*snip*
Problem is that XFreeDisplaySturture is checking for qelt->event.type ==
GenericEvent while _XUnknownWireEvent doesn't store the type.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Pauli Nieminen <ext-pauli.nieminen@nokia.com>
And there was much rejoicing.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Consensus on #xorg-devel agrees with removing --without-xcb; in
particular, acks from Adam Jackson, Daniel Stone, Kristian Høgsberg,
Julien Cristau, and Rémi Cardona.
imLcIm.c: In function '_XimCachedFileName':
imLcIm.c:361: warning: format '%03x' expects type 'unsigned int', but argument 8 has type 'long unsigned int'
imLcIm.c:364: warning: format '%03x' expects type 'unsigned int', but argument 8 has type 'long unsigned int'
imRm.c: In function '_XimDefaultArea':
imRm.c:597: warning: cast from pointer to integer of different size
imRm.c: In function '_XimDefaultColormap':
imRm.c:626: warning: cast from pointer to integer of different size
lcFile.c:224: warning: no previous prototype for 'xlocaledir'
lcUTF8.c: In function 'iconv_cstombs':
lcUTF8.c:1841: warning: assignment discards qualifiers from pointer target type
lcUTF8.c:1869: warning: pointer targets in passing argument 1 of 'wctomb' differ in signedness
lcUTF8.c:1873: warning: pointer targets in passing argument 1 of 'wctomb' differ in signedness
lcUTF8.c: In function 'iconv_mbstocs':
lcUTF8.c:1935: warning: pointer targets in passing argument 2 of 'mbtowc' differ in signedness
lcUTF8.c: In function 'iconv_mbtocs':
lcUTF8.c:2031: warning: pointer targets in passing argument 2 of 'mbtowc' differ in signedness
lcUTF8.c: In function 'iconv_mbstostr':
lcUTF8.c:2121: warning: pointer targets in passing argument 2 of 'mbtowc' differ in signedness
lcUTF8.c: In function 'iconv_strtombs':
lcUTF8.c:2180: warning: pointer targets in passing argument 1 of 'wctomb' differ in signedness
lcUTF8.c: In function '_XlcAddGB18030LocaleConverters':
lcUTF8.c:2367: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2368: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2373: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2374: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2375: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2376: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
lcUTF8.c:2377: warning: passing argument 5 of '_XlcSetConverter' from incompatible pointer type
XlibInt.c: In function '_XGetHostname':
XlibInt.c:3441: warning: implicit declaration of function 'gethostname'
XlibInt.c:3441: warning: nested extern declaration of 'gethostname'
ConnDis.c: In function '_XDisconnectDisplay':
ConnDis.c:540: warning: old-style function definition
ConnDis.c: In function '_XSendClientPrefix':
ConnDis.c:554: warning: old-style function definition
ConnDis.c: In function 'XSetAuthorization':
ConnDis.c:677: warning: old-style function definition
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
It's easier to reason about the code when we can't re-enter the
Xlib-private sync-handlers while they're already running.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
_XIDHandler and _XSeqSyncFunction originally ran from dpy->synchandler, and
thus had to return an int. Now, they only run from _XPrivSyncHandler or
LockDisplay, neither of which needs to check their return value since they
always returned 0. Make them both void.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
XID and sync handling happened via _XPrivSyncHandler, assigned to
dpy->synchandler and called from SyncHandle. _XPrivSyncHandler thus ran
without the Display lock, so manipulating the Display caused races, and
these races led to assertions in multithreaded code (demonstrated via
ico).
In the XTHREADS case, after you've called XInitThreads, we can hook
LockDisplay and UnlockDisplay. Use that to run _XIDHandler and
_XSeqSyncHandler from LockDisplay rather than SyncHandle; we then know
that we hold the lock, and thus we can avoid races. We think it makes
sense to do these both from LockDisplay rather than UnlockDisplay, so
that you know you have valid sync and a valid XID before you start
setting up the request you locked to prepare.
In the !XTHREADS case, or if you haven't called XInitThreads, you don't
get to use Xlib from multiple threads, so we can use the logic we have
now (with synchandler and savedsynchandler) without any concern about
races.
This approach gets a bit exciting when the XID and sequence sync
handlers drop and re-acquire the Display lock. Reacquisition will re-run
the handlers, but they return immediately unless they have work to do,
so they can't recurse more than once. In the worst case, if both of
them have work to do, we can nest the Display lock three deep. In the
case of the _XIDHandler, we drop the lock to call xcb_generate_id, which
takes the socket back if it needs to request more XIDs, and taking the
socket back will reacquire the lock; we take care to avoid letting
_XIDHandler run again and re-enter XCB from the return_socket callback
(which causes Very Bad Things, and is Not Allowed).
Tested with ico (with 1 and 20 threads), and with several test programs
for XID and sequence sync. Tested with and without XInitThreads(), and
with and without XCB.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=23192
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Generic events require more bytes than Xlib provides in the standard XEvent.
Memory allocated by the extension and stored as pointers inside the event is
prone to leak by simple 'while (1) { XNextEvent(...); }' loops.
This patch adds cookie handling for generic events. Extensions may register
a cookie handler in addition to the normal event vectors. If an extension
has registered a cookie handler, _all_ generic events for this extensions
must be handled through cookies. Otherwise, the default event handler is
used.
The cookie handler must return an XGenericEventCookie with a pointer to the
data.The rest of the event (type, serialNumber, etc.) are to be filled as
normal. When a client retrieves such a cookie event, the data is stored in
an internal queue (the 'cookiejar'). This data is freed on the next call to
XNextEvent().
New extension interfaces:
XESetWireToEventCookie(display, extension_number, cookie_handler)
Where cookie_handler must set cookie->data. The data pointer is of arbitray
size and type but must be a single memory block. This memory block
represents the actual extension's event.
New client interfaces:
XGetEventData(display, *cookie);
XFreeEventData(display, *cookie);
If the client needs the actual event data, it must call XGetEventData() with
the cookie. This returns the data pointer (and removes it from the cookie
jar) and the client is then responsible for freeing the event with
XFreeEventData(). It is safe to call either function with a non-cookie
event. Events unclaimed or not handled by the XGetEventData() are cleaned up
automatically.
Example client code:
XEvent event;
XGenericEventCookie *cookie = &ev;
XNextEvent(display, &event);
if (XGetEventData(display, cookie)) {
XIEvent *xievent = cookie->data;
...
} else if (cookie->type == GenericEvent) {
/* handle generic event */
} else {
/* handle extension/core event */
}
XFreeEventData(display, cookie);
Cookies are not multi-threading safe. Clients that use XGetEventData() must
lock between XNextEvent and XGetEventData to avoid other threads freeing
cookies.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The code is wrong since the first git revision, so it seens that it has
not been compiled with WORD64 for quite some time, there is also another
interesting code in xkb/XKBRdBuf.c:
<hash>ifdef WORD64
_XkbWriteCopyData32 Not Implemented Yet for sizeof(int)==8
<hash>endif
and possibly there are other similar problems.
Only convert to use "ansi prototypes" the functions warned from
compilation with "./autogen.sh --prefix=/usr", on a Linux computer.
Also, only address "trivial" compiler warning fixes in this commit.
The new .gitignore is the output of a command like:
% find . -name .gitignore -exec cat {} \; | sort | uniq
and only the toplevel .gitignore file was kept.
Xlib has several independent tasks that need to be performed with the
display unlocked. It does this by replacing the existing sync handler with
one of a variety of internal sync handlers. However, if multiple internal
sync handlers need to run, then the last one registering wins and
previously registered internal sync handlers are never invoked. This
manifested as a bug with DRI applications on Xlib/XCB as that requires
both an XID handler after every XID allocation, and the periodic sequence
number handler. The XID handler would win, and the sequence number handler
would never be invoked.
Fix this by unifying the internal sync handler mechanism into a single
function that calls all of the known internal sync handlers. They all need
to deal with being called when not strictly necessary now.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Josh Triplett <josh@freedesktop.org>
I refuse to take any responsibily for this code. It works, I guess.
But - all the flushing is done somewhere before that, so we might need to
flush here. Under some circumstances anyway. Don't ask me, I'm an optical
illusion.
Build with xcb as transport layer highly recommended.
If given many requests without replies, Xlib may not sync until it flushes
the output buffer. Thus, if Xlib can fit enough requests in the buffer to
pass by the number of requests it would normally sync after (65536 -
BUFSIZE/sizeof(xReq)), it will sync too late. The test case in bug 15023
demonstrated this by issuing a request with a reply (ListExtensions) at
just the right time to get confused with the GetInputFocus reply issued in
response to the sync 65,536 requests later; the test case used an async
handler to watch the replies, since otherwise it could not issue a request
without waiting for the response. When the test case failed, Xlib's sync
handler would eat the ListExtensions reply, and the test case's async
handler would see the GetInputFocus reply.
Fix this by replacing SEQLIMIT with a function sync_hazard() that uses the
buffer size to figure out when the sequence numbers could potentially wrap
before the next flush.
With this commit, the test case consistently passed, and the async reply
handler always saw the ListExtensions reply.
Commit by Jamey Sharp and Josh Triplett.
Some libraries try to clean up X resources from atexit handlers, _fini,
or C++ destructors. To make these work, the Display lock should be
downgraded to a user lock (as in XLockDisplay) before calling exit(3).
This blocks Xlib calls from threads other than the one calling exit(3)
while still allowing the exit handlers to call Xlib.
This assumes that the thread calling exit will call any atexit handlers.
If this does not hold, then an alternate solution would involve
registering an atexit handler to take over the lock, which would only
assume that the same thread calls all the atexit handlers.
Commit by Josh Triplett and Jamey Sharp.
- For Xcomposite and Xdamage, don't link the build system out of the xc tree
- Link the public X11 headers into their own directory
- Add links to XKeysymDB and XErrorDB
- Add links to all the Xlib man pages
- Add links to the lcUniConv subdirectory
- Conditionally include config.h in Xlib source
