Use abort() instead of exit() in xio error handler?

Lubos Lunak l.lunak at suse.cz
Thu Jun 4 09:34:06 BST 2009


On Thursday 04 of June 2009, Christoph Feck wrote:
> My primary question was about
> "global objects should survive XIO errors". As I see it now, Qt does not
> "signal" the application that the connection to the display server is lost,
> but simply expects the application to handle that error itself.

 Qt even can't do that. The XIO handler is expected not to return, so it can't 
do better than some kind of exit().

> I was referring to https://bugs.kde.org/show_bug.cgi?id=178844 alias
> https://bugs.freedesktop.org/show_bug.cgi?id=14211 alias
> https://bugs.launchpad.net/xorg-server/%2Bbug/185311 but it looks like this
> seems to be fixed now, the upstream bug report has not been closed, though.
>
> I have seen some other backtraces that looked quite different, but all had
> the same problem: a crash appeared somewhere after exit() being called
> because of the XIO error, but with global objects still referencing stuff,
> see my comment #2 in bug 178844.

 We call exit() also in some other places. I still think that changing the XIO 
handler will only cover up a real problem, nothing else. In #178844, 
something caused the XIO handler to be collect, most probably a memory 
corruption. That's (very likely) not a fault of X but of the application.

 The same way, the calling of that global object on exit() in #178844 looks 
like an application bug to me. If it references stuff that's gone by the time 
global objects are destructed, then it's simply broken.

> As far as I understand it, XCB had issues with improper locking, causing
> race conditions that eventually raised the XIO errors

 No. The only issue with XCB is that it is more strict WRT locking and 
incorrectly written Xlib applications now suddenly hit those asserts. That 
doesn't change anything about the fact that those applications are still 
broken and that the XCB changes mentioned from the X bugreport will only 
(also) make XCB again more tolerant of such sloppy code. So there is no "evil 
XCB bug".

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 084 672
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz




More information about the kde-core-devel mailing list