On 13 October 2011 20:10, Daniel Stone <[email protected]> wrote: > Hi, > > On 13 October 2011 17:53, Keith Packard <[email protected]> wrote: >> On Thu, 13 Oct 2011 14:49:42 +0100, Simon Farnsworth >> <[email protected]> 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. Thanks Michal _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
