| Age | Commit message (Collapse) | Author |
|---|
|
The alternative is to use these in every WIN32 application which uses xcb. Doing
it this way should be safe, as, according to MSDN, "There must be a call to
WSACleanup for each successful call to WSAStartup. Only the final WSACleanup
function call performs the actual cleanup. The preceding calls simply decrement
an internal reference count"
(We should probably also include ws2_32 in Libs.private for libxcb, as anything
which links with libxcb will also need that, but there seems to be some pkg-config
issues to resolve first...)
v2: Check for errors so WSAStartup()/WSACleanup() uses are balanced
v3: Use same indentation style as surrounding code
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
|
|
Fix a redefinition problem due to include order which shows up when
building for _WIN32 and libXdmcp is installed, so HASXDMAUTH is enabled
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
|
|
WIN32 does not have arpa/inet.h, so do not try to include it unless _WIN32 is
not defined
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
Reviewed-by: Peter Harris <pharris@opentext.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
|
|
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=41443
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=42304
I have added more xcb connection error states at xcb.h header.
Also I have removed global error_connection variable, and added
an interface that returns connection error state.
TBD:
I will segregate errors states in a separate header file and try to
provide more precise error states, in future. Also I will give patch
for libX11, in that patch xcb_connection_t::has_error will be passed
to default io handler of libX11. This value can then be used for
displaying error messages.
Reviewed-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Reviewed-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Arvind Umrao <arvind.umrao@oracle.com>
|
|
_xcb_out_flush_to will drop the iolock in pthread_cond_wait allowing
other threads to queue new requests. When this happened,
there would be requests queued for the socket after _xcb_out_flush_to
returned, and xcb_take_socket would throw an assert.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29875
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
|
|
Imagine two threads:
Thread#1: for(;;) { xcb_get_input_focus_reply(c, xcb_get_input_focus(c), 0); }
Thread#2: for(;;) { xcb_poll_for_event(c); }
Since xcb_poll_for_event() calls _xcb_in_read() directly without synchronizing
with any other readers, this causes two threads to end up calling recv() at the
same time. We now have a race because any of these two threads could get read
the GetInputFocus reply.
If thread#2 reads this reply, it will be put in the appropriate queue and
thread#1 will still be stuck in recv(), although its reply was already received.
If no other reply or event causes this thread to wake up, the process deadlocks.
To fix this, we have to make sure that there is only ever one thread reading
from the connection. The obvious solution is to check in poll_for_next_event()
if another thread is already reading (in which case c->in.reading != 0) and not
to read from the wire in this case.
This solution is actually correct if we assume that the other thread is blocked
in poll() which means there isn't any data which can be read. Since we already
checked that there is no event in the queue this means that
poll_for_next_event() didn't find any event to return.
There might be a small race here where the other thread already determined that
there is data to read, but it still has to wait for c->iolock. However, this
means that the next poll_for_next_event() will be able to read the event, so
this shouldn't cause any problems.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=40372
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
Uli's patch is an excellent solution; I just want to keep the new
ALIGNOF macro hidden from XCB's users, as they don't need it to call
XCB.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
Some of these systems (eg. Interix on XP) are still in use.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
The code previously assumed that everything has to be aligned to a 4 byte
boundary. This assumption is wrong as e.g. the STR struct from xproto shows.
Instead, each type has to be aligned to its natural alignment. So a char doesn't
need any alignment, a INT16 gets aligned to a 2-byte-boundary and a INT32 gets
the old 4 byte alignment.
I'm not 100% sure that this commit is correct, but some quick tests with awesome
and cairo-xcb went well.
This commit causes lots of dead assignments to xcb_align_to since only the last
field's alignment is actually used, but this simplified this patch a lot.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=34037
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
When a system is completely offline (no interface has an IP address but 'lo'),
xcb could not connect to localhost via TCP, e.g. connections with
DISPLAY=127.0.0.1:0 fail.
AI_ADDRCONFIG will only return IPv4 addresses if the system has an IPv4
address configured (likewise for IPv6). This also takes place when
resolving localhost (or 127.0.0.0/8 or ::1). Also, as per RFC 3493,
loopback addresses are not considered as valid addresses when
determining whether to return IPv4 or IPv6 addresses.
As per mailing-list discussion on the xcb list started with message
20110813215405.5818a0c1@x200, the AI_ADDRCONFIG flag is there for historical
reasons:
In the old days, the "default on-link" assumption in IPv6 made the flag vey
much indispensable for dual-stack hosts on IPv4-only networks. Without it,
there would be long timeouts trying non-existent IPv6 connectivity. Nowadays,
this assumption has been flagged as historic bad practice by IETF, and hosts
should have been updated to not make it anymore.
Then AI_ADDRCONFIG became mostly cosmetic: it avoids phony "Protocol family
not supported" or "Host unreachable" errors while trying to connect to a dual-
stack mode from a host with no support for source address selection.
Nowadays, on up-to-date systems, this flag is completely useless. Then again,
I understood only the very latest MacOS release is "up-to-date" with this
definition.
|
|
If a the path to the xcb python generate libs is
explicitly specified to c_client.py, insert it in
the python path list just after the local dir entry,
rather than appending it to the existing paths.
This keeps a global/distro install of xcb from
overriding a local build of the xcb proto files.
Signed-off-by: James Jones <jajones@nvidia.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
Python 3 introduces some language changes that cause issues when running
c_client.py. This also breaks compatibility with Python 2.5 since it does not
support the "as" statement in try/except blocks and does not have reduce() in
the functools package.
The main changes are:
* try/except blocks require `except ... as ...:` to resolve syntactical ambiguity
* map() and filter() return iterators rather than lists in Python 3
* reduce() is now in functools package (and not built-in in Python 3)
* Dictionaries don't have a has_key() method in Python 3
* None and int types can't be directly compared in Python 3
* print() is a statement in Python 3
See http://diveintopython3.org/porting-code-to-python-3-with-2to3.html and
PEP-3110 for details.
Verified on Python 2.6.5 and 3.1.3.
Signed-off-by: David Coles <dcoles@gaikai.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
|
|
wire-order."
This function was intended to allow libX11 to fix a multi-threaded hang,
but the corresponding libX11 patch caused single-threaded apps to spin
sometimes. Since I've retracted that patch, this patch has no users and
shouldn't go into a release unless/until that changes.
This reverts commit 2415c11dec5e5adb0c17f98aa52fbb371a4f8f23.
Conflicts:
src/xcb.h
src/xcb_in.c
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
In some circumstances using xcb_poll_for_event is suboptimal because
it checks the connection for new events. This may lead to a lot of
failed nonblocking read system calls.
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
Fixes fallback to local connections from Xlib's XOpenDisplay(), which
will try with protocol "unix" if a hostname is specified and tcp fails
(as it usually will now that most OS'es ship with -nolisten tcp enabled).
Also fixes explicitly specifying DISPLAY as "unix/foo:0", which Xlib
previously accepted for Unix domain sockets.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
|
This patch is necessary so xcb reads the payload after the message
for GenericEvents with the 0x80 flag turned on.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
Solves compiler warning on Solaris:
"xcb_conn.c", line 304: warning: implicit function declaration: shutdown
Also provides system definition of SHUT_RDWR on Solaris 11.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
|
|
"unifdef -UDNETCONN src/xcb_util.c" plus re-indenting code that was
formerly in the else clause after a DECnet check.
DECnet support has been removed from most of the X.Org code base for
several years, and it appears DNETCONN was never defined in XCB.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
|
|
Solaris Trusted Extensions puts the endpoints for the X server's Unix
domain sockets in a special directory shared from the global zone to
each of the labeled zones, since each labeled zone has a separate /tmp.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Harris <pharris@opentext.com>
|
|
Variable new_sockname will leak and sockname will be double freed if
both of the cases shown below are true.
1. realloc succeeds and doesn't return the original pointer
2. calling socket_func fails
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
Reviewed-by: Arnaud Fontaine <arnau@debian.org>
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
It hasn't been used since libxcb 1.1.90.1, released in 2008.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
|
|
Later patches will insert reader_list entries from other entry points.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Josh Triplett <josh@freedesktop.org>
|
|
It's possible to call xcb_wait_for_reply more than once for a single
request. In this case we are nice and let reply waiters continue so
that they can notice that the reply is not available
anymore. Otherwise an event waiter could just signal the reply waiter
that got its reply to continue but leave a waiter for an earlier reply
blocked.
Below is an example sequence for reproducing this problem.
thread #1 (XNextEvent)
- waits for events
thread #2 (XSync)
- executes request #2
- waits for reply #2
thread #1
- reads reply #2
- signals waiter of reply #2 to continue
- waits for events
thread #2
- handles reply #2
thread #3 (XCloseDisplay)
- executes request #3
- waits for reply #2
thread #1
- reads reply #3
- nobody is waiting for reply #3 so don't signal
- wait for events
Of course it may be questionable to wait for a reply twice, but XCB
should be smart enough to let clients continue if they choose to do
so.
Signed-off-by: Rami Ylimäki <rami.ylimaki@vincit.fi>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
Apparently I forgot to push these months ago.
|
|
sizeof(void) is a gcc extension, and not portable.
Xorg Bugzilla 31959
http://bugs.freedesktop.org/show_bug.cgi?id=31959
http://lists.freedesktop.org/archives/xcb/2010-May/006039.html
Signed-off-by: Peter Harris <pharris@opentext.com>
Tested-by: Cyril Brulebois <kibi@debian.org>
|
|
|
|
|
|
Windows' file handles have never been small or consecutive, so Windows'
select has always been implemented the same way as everyone else's poll.
On Windows, FD_SETSIZE is the size of the poll array, not the maximum
SOCKET number.
Signed-off-by: Peter Harris <git@peter.is-a-geek.org>
|
|
If lots of requests are send without one causing a reply, xcb can get confused
about the current sequence number of a reply. Document the requirements of an
external socket owner to avoid this problem.
The return_socket callback for xcb_take_socket() originally was supposed to
return the last sequence number used, but the version committed to libxcb never
actually had this signature. This fixes the function's documentation not to
mention this non-existent return value.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
|
|
If the initial get_peer_sock_name(getpeername ...) succeeds, the
pointer to allocated memory is overwritten by the later call to
get_peer_sock_name(getsockname ...). Fix that up by freeing
the allocated memory before overwriting the pointer.
Signed-off-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Julien Danjou <julien@danjou.info>
|
|
Widen sequence numbers on entry to those public APIs that still take
32-bit sequence numbers.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
If you discard a sequence number that has multiple responses already
read, this will do more allocations than necessary. But nobody cares
about ListFontsWithInfo.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
This simplifies the critical section of xcb_send_request and fixes a
couple of subtle bugs:
- It's possible for xcb_send_request to need to issue two sync requests
before it can issue the real request. Previously, we counted sequence
numbers as if both were issued, but only one went out on the wire.
- The test for whether to sync at 32-bit sequence number wrap has been
incorrect since we switched to 64-bit sequence numbers internally.
This change means that if the output queue was already full and the
current request is bigger than the output queue, XCB will do one more
write syscall than it did before. But syncs are rare and small requests
are the norm, so this shouldn't be a measurable difference.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
This cleans up a number of warnings, and passes the sequence number
through correctly.
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
By calling memmove instead of memcpy, and walking the buffer backward
from the end, *_unserialize is safe to use in-place.
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
In support of this, consolidate the two static error_connection
definitions into one so we don't try to free the static out-of-memory
error_connection.
Commit by Josh Triplett and Jamey Sharp.
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
|
|
If a client calls close(2) on the connection's file descriptor and then
flushes writes, libxcb causes a hang in the client.
Any flush eventually calls _xcb_out_send() with has the following loop:
while(ret && *count)
ret = _xcb_conn_wait(c, &c->out.cond, vector, count);
_xcb_conn_wait(), if built with USE_POLL, gets the POLLNVAL error. It only
checks for POLLIN and POLLOUT though, ignoring the error. Return value is 1,
count is unmodified, leaving us with an endless loop and a client hang.
XTS testcase Xlib3/XConnectionNumber triggers this bug. It creates a display
connection, closes its file descriptor, tries to send a no-op, and then expects
an error.
http://cgit.freedesktop.org/xorg/test/xts/tree/xts5/Xlib3/XConnectionNumber.m
If poll returned POLLHUP or POLLERR, we might see the same result.
If poll returns any event we didn't ask for, this patch causes
_xcb_conn_shutdown() to be invoked and an error returned. This matches the
behaviour if select(2) is used instead of poll(2): select(2) returns -1 and
EBADF for an already closed file descriptor.
I believe this fix both is safe and will handle any similar error. POSIX says
that the only bits poll is permitted to set in revents are those bits that were
set in events, plus POLLHUP, POLLERR, and POLLNVAL. So if we see any flags we
didn't ask for then something has gone wrong.
Patch inspired by earlier proposals from Peter Hutterer and Aaron
Plattner--thanks!
Reported-by: Peter Hutterer <peter.hutterer@who-t.net>
Reported-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Cc: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
Conflicts:
src/xcb_conn.c
src/xcb_util.c
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
Fixes the X Test Suite's XCloseDisplay-6 test, which has this (admittedly
ridiculous) behavior:
1. Create a window w.
2. Open two display connections, dpy1, and dpy2.
3. Grab the server using dpy1.
4. Fork.
5 (child). XSetProperty on w using dpy2.
5 (parent). Verify that no event was recieved on dpy1.
6 (parent). XCloseDisplay(dpy1).
6 (child). Verify that an event was received on dpy2.
It was failing because at step 6 (child), the server had not actually ungrabbed
yet because the file descriptor for dpy1 was still open in the child process.
Shutting down the socket during XCloseDisplay matches the behavior of non-XCB
Xlib, which calls shutdown() from _X11TransSocketDisconnect.
Thanks to Julien Cristau for noticing this.
Signed-off-by: Aaron Plattner <aplattner at nvidia.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Peter Harris <pharris@opentext.com>
|
|
This fixes the test case I have so far for Havoc's report that
xcb_request_check hangs.
Rationale: Since we have a void cookie, request_expected can't have been
set equal to this sequence number when the request was sent; it can only
have become equal due to the arrival of an event or error. If it became
equal due to an event then we still need to sync. If it became equal due
to an error, then request_completed will have been updated, which means
we correctly won't sync.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=29599
However, Havoc reports that he can still reproduce the problem, so we
may be revisiting this later.
Reported-by: Havoc Pennington <hp@pobox.com>
Signed-off-by: Jamey Sharp <jamey@minilop.net>
|
|
also added very basic documentation for xkb
|
