[PATCH-V4] xserver: Optional backtrace handler

Michal Suchanek hramrach at centrum.cz
Thu Oct 13 14:15:04 PDT 2011

On 13 October 2011 20:10, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
> On 13 October 2011 17:53, Keith Packard <keithp at keithp.com> wrote:
>> On Thu, 13 Oct 2011 14:49:42 +0100, Simon Farnsworth <simon.farnsworth at onelan.co.uk> wrote:
>>> A question - what is it about preforking a backtrace handler that you think
>>> will put people off using it?
>> It's an ugly hack to work around a bug in glibc. A non-prefork version
>> wouldn't consume any resources until the server actually crashes.
>> If we knew that systems which did not have syscall(2) also had a working
>> fork(2), then we could simply use syscall(SYS_fork) where available and
>> expect that to work around any potential glibc bugs.
> Or, just accept that once you've not only segfaulted but are
> attempting to carry on and deal with the crash post-mortem, with the
> server in god-knows-what state, it's always going to be best-effort
> and you might not always be able to do everything you'd ever wanted.
> *shrug*

I guess the backtrace handler is useful. Even if you normally don't
run it and have to enable it in advance.

It allows you to record a backtrace with a single machine only.

Due to X deadlocking the VT switch in kernel you can't do that without
access from another machine normally.

Also distributions can ship a config.d with a package containing the X
server debug symbols to enable it automagically and make bug reports
more useful.



More information about the xorg-devel mailing list