1. 05 Nov, 2007 1 commit
    • Jamey Sharp's avatar
      Revert "Generate error constants as XCB_BAD_*, similar to Xlib." · af50de26
      Jamey Sharp authored
      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 158c9b6b.
  2. 28 Oct, 2007 2 commits
  3. 23 Oct, 2007 1 commit
    • Jamey Sharp's avatar
      Don't abort() on locking assertions if LIBXCB_ALLOW_SLOPPY_LOCK is set. · 4d828c5e
      Jamey Sharp authored
      But do still print a full backtrace, on platforms where that's
      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
      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's avatarJamey Sharp <jamey@minilop.net>
      Acked-by: Josh Triplett's avatarJosh Triplett <josh@freedesktop.org>
  4. 19 Jul, 2007 1 commit
  5. 14 Jun, 2007 1 commit
  6. 06 Jun, 2007 1 commit
    • Christoph Pfister's avatar
      Print backtraces in case an assert fails inside xlib/xcb. · 605c778e
      Christoph Pfister authored and Jamey Sharp's avatar Jamey Sharp committed
      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.
      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.
      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's avatarJamey Sharp <jamey@minilop.net>
  7. 03 Jun, 2007 1 commit
  8. 18 Apr, 2007 1 commit
  9. 13 Apr, 2007 1 commit
  10. 12 Apr, 2007 2 commits
  11. 11 Apr, 2007 1 commit
  12. 10 Apr, 2007 1 commit
  13. 29 Mar, 2007 1 commit
  14. 27 Feb, 2007 1 commit
  15. 07 Feb, 2007 3 commits
  16. 06 Feb, 2007 1 commit
  17. 22 Jan, 2007 1 commit
  18. 13 Jan, 2007 1 commit
  19. 11 Dec, 2006 2 commits
  20. 28 Nov, 2006 5 commits
  21. 26 Nov, 2006 2 commits
  22. 25 Nov, 2006 2 commits
  23. 24 Nov, 2006 2 commits
  24. 23 Nov, 2006 5 commits
    • Josh Triplett's avatar
      Release libxcb 1.0 · 27f98afc
      Josh Triplett authored
    • Diego 'Flameeyes' Pettenò's avatar
      Avoid race condition when using multiple make jobs · 11738b2a
      Diego 'Flameeyes' Pettenò authored and Josh Triplett's avatar Josh Triplett committed
      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.
    • Josh Triplett's avatar
      Rewrite automake's data installation rules, because they suck. · 30c768b3
      Josh Triplett authored
      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.
    • Josh Triplett's avatar
      Rework doxygen build and install to work with srcdir != builddir · af3a1583
      Josh Triplett authored
      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.
    • Josh Triplett's avatar
      Remove --with-opt and --with-debug options from configure.ac; use CFLAGS instead · 608058ec
      Josh Triplett authored
      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.