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>
xcb-xinerama.pc.in looked more like a generated .pc file; replace specific
instances of values provided by an invocation of configure with the general
substitution variables configure replaces.
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.
Specifically, they didn't handle installing data from both srcdir and builddir.
We have the tutorial in the srcdir, and build the manual in the builddir.
Also, stop rebuilding the manual for each make target in the doc directory, and
every time any of those targets get called. This change now makes the manual
never rebuild once built; we plan to fix that later, by rewriting the makefiles
to avoid recursive make, and then making the manual depend on the source files.
Commit by Jamey Sharp and Josh Triplett.
The documentation generation with doxygen now works when built out of tree,
with srcdir != builddir. xcb.doxygen now gets generated from xcb.doxygen.in,
so that it can use top_builddir and top_srcdir to find source and to output
documentation. Also fill in PROJECT_NUMBER from @VERSION@, now that we have
it readily available via autoconf.
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.