1. 24 Nov, 2007 1 commit
  2. 05 Nov, 2007 3 commits
  3. 28 Oct, 2007 2 commits
  4. 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
      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's avatarJamey Sharp <jamey@minilop.net>
      Acked-by: Josh Triplett's avatarJosh Triplett <josh@freedesktop.org>
      4d828c5e
  5. 19 Jul, 2007 1 commit
  6. 14 Jun, 2007 1 commit
  7. 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.
          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's avatarJamey Sharp <jamey@minilop.net>
      605c778e
  8. 03 Jun, 2007 1 commit
  9. 22 May, 2007 4 commits
  10. 18 Apr, 2007 1 commit
  11. 13 Apr, 2007 1 commit
  12. 12 Apr, 2007 2 commits
  13. 11 Apr, 2007 1 commit
  14. 10 Apr, 2007 1 commit
  15. 29 Mar, 2007 1 commit
  16. 27 Feb, 2007 1 commit
  17. 07 Feb, 2007 3 commits
  18. 06 Feb, 2007 1 commit
  19. 22 Jan, 2007 1 commit
  20. 13 Jan, 2007 1 commit
  21. 11 Dec, 2006 5 commits
  22. 28 Nov, 2006 5 commits
  23. 26 Nov, 2006 1 commit