GenericEvent can be more than 32 bytes long. Ensure that the required data is
pulled off the wire and tack it onto the event.
Due to the structure of the xcb_generic_event_t, the data is appended AFTER
the full_sequence field.
Since several extensions named their errors like "BadFoo", this patch
results in names like XCB_EXT_BAD_BAD_FOO, which is really awful. Those
extensions are already kind of awful, as they produce structure names
like xcb_ext_bad_foo_error_t, which is redundant.
A patch that removes "Bad" from the XML extension descriptions, while
maintaining API and ABI compatibility in XCB, is needed before this
patch can be released.
This reverts commit 158c9b6ba1.
With this patch, `ico -threads 2` runs without deadlock.
Many thanks to Christoph Pfister <christophpfister@gmail.com> for
pointing out the problem, providing detailed analyses, explaining it to
me repeatedly until I understood what was going on, and proposing and
reviewing possible solutions.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Acked-by: Christoph Pfister <christophpfister@gmail.com>
But do still print a full backtrace, on platforms where that's
supported.
This commit follows the spirit of Novell's libxcb-sloppy-lock.diff.
I strongly opposed proposals like this one for a long time. Originally I
had a very good reason: libX11, when compiled to use XCB, would crash
soon after a locking correctness violation, so it was better to have an
informative assert failure than a mystifying crash soon after.
It took some time for me to realize that I'd changed the libX11
implementation (for unrelated reasons) so that it could survive most
invalid locking situations, as long as it wasn't actually being used
from multiple threads concurrently.
The other thing that has changed is that most of the code with incorrect
locking has now been fixed. The value of the assert is accordingly
lower.
However, remaining broken callers do need to be fixed. That's why libXCB
will still noisily print a stacktrace (if possible) on each assertion
failure, even when assert isn't actually invoked to abort() the program;
and that's why aborting is still default. This environment variable is
provided only for use as a temporary workaround for broken applications.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Acked-by: Josh Triplett <josh@freedesktop.org>
As you know there are some nasty libs / apps doing locking
incorrectly. In order to improve the information given to the user
when he encounters such a situation (people don't run apps in gdb
normally) I created the patch attached.
It's very non-intrusive (and affects only xlib/xcb, Josh told me on
irc that it could be useful for other areas too, personally I don't
think that it's really needed at other places ...).
Some same outputs and the discussion of them:
lxuser@pdln:/tmp$ ./main
Got a backtrace:
#0 /tmp/usr/lib/libxcb-xlib.so.0 [0xb7f9d728]
#1 /tmp/usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb7f9d861]
#2 ./test.so(function_a+0x11) [0xb7f9f3fd]
#3 ./test.so(function_b+0x11) [0xb7f9f410]
#4 ./main [0x80484a7]
#5 /lib/libc.so.6(__libc_start_main+0xdc) [0xb7e60ebc]
#6 ./main [0x80483f1]
main: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted
That's kinda the normal situation.
lxuser@pdln:/tmp$ ./main
Got a backtrace:
#0 /tmp/usr/lib/libxcb-xlib.so.0 [0xb7f90728]
#1 /tmp/usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x31) [0xb7f90861]
#2 /tmp/test.so [0xb7f923cd]
#3 /tmp/test.so(function_b+0x11) [0xb7f923e0]
#4 ./main [0x80484ab]
#5 /lib/libc.so.6(__libc_start_main+0xdc) [0xb7e53ebc]
#6 ./main [0x80483f1]
main: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted
There are two possible reasons that the name doesn't appear in #2:
a) a hidden symbol or a symbol with statical linkage in a library
b) a symbol in an app not compiled with -rdynamic.
But in both cases you still know _where_ the caller is.
Note that in this example test.so was compiled with
-fomit-frame-pointer; this isn't an issue as _one_ (= the caller)
stack trace is still valid (as long as you don't have the insane idea
to compile xcb with -fo-f-p).
Another issue that may appear is "tail call elimination" (some entries
are mysteriously missing; this is quite ugly, but you still get enough
information so that you can do something useful with the issue e.g. by
disassembling the relevant parts with gdb).
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Avoid race condition when symlinking XML files.
When declaring a rule with many files as target, the rule is called
when any of them is requested, resulting in multiple for loops happening
during a make process using more than one job.
Also, use '$(LN_S) -f' rather than removing and recreating a file,
that one should be as supported as 'rm -f' and requires one less command.
configure supports using custom CFLAGS, so remove the --with-opt and
--with-debug options from configure.ac, and the corresponding usage of
COPTFLAGS and CDEBUGFLAGS in src/Makefile.am.
Change xcb_connect to pass the display number to _xcb_get_auth_info, which
passes it to get_authptr. This allows get_authptr to stop hacking the display
number out of the sockaddrs of various address families, such as
port - X_TCP_PORT, or the number after the last X in the UNIX socket path. This
also removes a portability bug introduced during the IPv6 changes: relying on
'\0'-termination of the UNIX socket path in a sockaddr_un.
Commit by Jamey Sharp and Josh Triplett.
xcb_parse_display already correctly handled IPv6 displays. Now, _xcb_open_tcp
uses getaddrinfo, and correctly connects to IPv6 displays. Displays can use
bare IPv6 addresses, square-bracketed IPv6 addresses, or hostnames which
resolve to IPv6 addresses.
Since IPv6 addresses may include colons, including at the end, revise the
DECnet display parsing code to avoid triggering on IPv6 addresses.
Authorization may not work with IPv6 connections yet.
This commit brought to you by the (display) number ::1:1.1, the letter X,
the Gobby collaborative editor, Josh Triplett, and Jamey Sharp.
Only one use of <localfield> remained, for a list length expression in
xv.xml. List length parameters that don't actually appear in the
protocol should be left implicit: if no length expression is given, then
a localfield will be automatically created by c-client.xsl.
Specifically, fixes these two warnings which were emitted for every
generated source file:
* Warning: end of file while inside a group
* Warning: group XCB_BigRequests_API already documented. Skipping documentation.
Hard coding the opcode numbers in the function just makes it harder to figure
out what's going on, but much more to the point, not defining the opcodes in
the header makes it impossible to use the generated headers instead of the
x11proto headers in the server.
The name I settled on is very simple, for an extension by the name of xconf,
and a request by the name of list_devices, we get XCB_XCONF_LIST_DEVICES. If
this somehow causes problems, we can probably add a _OP somewhere in there,
but.
Acked-by: Jamey Sharp <jamey@minilop.net>
Closes: #8641
The initial implementation of Plan 7 dumped all X errors into the event
queue, because the record of a pending reply was pruned too early if an
error occurred in place of the expected reply.
Since extensions no longer provide type-specific XID-generation functions,
xcb_generate_id now forms part of the xcb client API, rather than the
extension API; move it from xcbext.h to xcb.h accordingly.
After positive feedback from several people, we have decided to remove the XID
wrapper structures that attempted to provide C type safety, and replace them
with uint32_t typedefs. Feedback has indicated that these type-safety hacks
generated more trouble than help.
We will bump the libxcb soname at the next release.
We don't want to have to change the libxcb soname if we later manage to remove
the Xlib compatibility functions, and nothing except Xlib should ever use
them, so split them into a separate library.
Rename API to follow a new naming convention:
* XCB_CONSTANTS_UPPERCASE_WITH_UNDERSCORES
* xcb_functions_lowercase_with_underscores
* xcb_types_lowercase_with_underscores_and_suffix_t
* expand all abbreviations like "req", "rep", and "iter"
Word boundaries for the names in the protocol descriptions fall:
* Wherever the protocol descriptions already have an underscore
* Between a lowercase letter and a subsequent uppercase letter
* Before the last uppercase letter in a string of uppercase letters followed
by a lowercase letter (such as in LSBFirst between LSB and First)
* Before and after a string of digits (with exceptions for sized types like
xcb_char2b_t and xcb_glx_float32_t to match the stdint.h convention)
Also fix up some particular naming issues:
* Rename shape_op and shape_kind to drop the "shape_" prefix, since otherwise
these types end up as xcb_shape_shape_{op,kind}_t.
* Remove leading underscores from enums in the GLX protocol description,
previously needed to ensure a word separator, but now redundant.
This renaming breaks code written for the previous API naming convention. The
scripts in XCB's tools directory will convert code written for the old API to
use the new API; they work well enough that we used them to convert the
non-program-generated code in XCB, and when run on the old program-generated
code, they almost exactly reproduce the new program-generated code (modulo
whitespace and bugs in the old code generator).
Authors: Vincent Torri, Thomas Hunger, Josh Triplett
The installed headers can't be relying on the presence of the internal
config.h defines, and it was breaking the xcb build for me as well due to
config.h not being included early enough.
Create a macro, XCB_SEQUENCE_COMPARE, that accepts two sequence numbers and
a comparison operator and correctly handles 32-bit wrap around.
Rewrite all ordered sequence number comparisons to use this macro.
Also, caught one error where a sequence was stored in a signed int variable.
Push out a GetInputFocus request when the sequence number does wrap at 32
bits so that applications cannot see sequence 0 (as that is an error
indicator).
libXCBextname. To use extension extname, include extname.h and link with
-lXCBextname. This allows extensions to change without bumping the main
libXCB version.
bigreq and xc_misc remain in libXCB, because XCB uses them internally to make
big requests and to allocate XIDs, respectively.
This requires dynamically allocating memory in XCBSendRequest, but this
malloc/free pair turns out to cause a 30% speed hit for the 'x11perf -noop'
test -- so for the moment I use alloca where available and fall back to malloc
on other platforms. Later I think I'll change the contract of XCBSendRequest
so the caller is responsible for memory allocation, because the caller ought
to always be able to stack-allocate here.
Josh Triplett
Peter Hutterer
Oswald Buddenhagen
Eamon Walsh
Jeremy Kolb
Bart Massey
Jamey Sharp
Egbert Eich
Christoph Pfister
Ian Osgood
TORRI Vincent
TORRI Vincent
Diego 'Flameeyes' Pettenò
Jeremy Kolb jkolb@brandeis.edu
Zephaniah E. Hull
Jeremy Kolb
Alan Coopersmith
Bart Massey
Eric Anholt
Keith Packard
Donnie Berkholz
Patrick Caulfield
Ian Osgood
TORRI Vincent