Skip to content
  • 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: default avatarJamey Sharp <jamey@minilop.net>
    Acked-by: default avatarJosh Triplett <josh@freedesktop.org>
    4d828c5e