[Xcb] print backtraces in case an assert fails inside xlib/xcb

[Barton C Massey]

Thanks hugely---this is awesome, and really needed doing.
The thing it will help with that I'm most excited about is
deciding whether the bug is in the app itself or in some
stale or broken X library being called by the app.

If Josh doesn't apply this in the next couple of days, bug
me and I will (unless someone has a cogent objection).
Also, let us know if you want commit privs.

BTW, might want to add a line or two to indicate when the
backtrace has been truncated to 20 lines...

	Bart

In message <19a3b7a80706061338g39064f70tfb9f236240aafef2 at mail.gmail.com> you wrote:
> ------=_Part_40173_31275033.1181162296404
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> Hi,
> 
> 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 at 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 at 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).
> 
> Christoph
> 
> ------=_Part_40173_31275033.1181162296404
> Content-Type: text/plain; name=printbts.diff; charset=ANSI_X3.4-1968
> Content-Transfer-Encoding: base64
> X-Attachment-Id: f_f2m8wgn2
> Content-Disposition: attachment; filename="printbts.diff"
> 
> ZGlmZiAtZE5wcnUgYS9jb25maWd1cmUuYWMgYi9jb25maWd1cmUuYWMKLS0tIGEvY29uZmlndXJl
> LmFjCTIwMDctMDYtMDYgMTc6MTM6MDYuMDAwMDAwMDAwICswMjAwCisrKyBiL2NvbmZpZ3VyZS5h
> YwkyMDA3LTA2LTA2IDE3OjE1OjMxLjAwMDAwMDAwMCArMDIwMApAQCAtNDgsNiArNDgsOCBAQCBQ