From: Jamey Sharp Date: Tue, 23 Oct 2007 18:03:33 +0000 (-0700) Subject: Don't abort() on locking assertions if LIBXCB_ALLOW_SLOPPY_LOCK is set. X-Git-Url: http://git.demorecorder.com/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=4d828c5eba9fc7161c5f18650f2dbe218e1db06f;hp=4d828c5eba9fc7161c5f18650f2dbe218e1db06f;p=free-sw%2Fxcb%2Flibxcb Don't abort() on locking assertions if LIBXCB_ALLOW_SLOPPY_LOCK is set. 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 Acked-by: Josh Triplett ---