On Wednesday, 10 October 2018 00:50:10 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > You can call _exit. You can't call much else. You can only call the > > functions listed in this man page from a signal handler: > > http://man7.org/linux/man-pages/man7/signal-safety.7.html > > > > NEVER allocate memory and NEVER lock a mutex in a signal handler. > > So you are basically saying that KDevelop is doing it all wrong and that > it's purely by chance that this works (when the X server is responsive)? > > https://github.com/KDE/kdevelop/blob/master/kdevplatform/shell/core.cpp#L54 > > (not looking to point fingers, just to know if there's room for improvement)
Yes. That code is a timebomb waiting to go off. Or maybe a better metaphor is a Russian roulette, since it depends on what the other threads are doing, meaning you can be lucky most of the time. The qCDebug and QApplication::closeAllWindows allocate memory, so they can deadlock inside malloc(). QCoreApplication::quit() doesn't, but it's not async-signal safe either. > And a complementary question: why does QXcbConnection::processXcbEvents() > call exit() when the X server (probably) died, if that's not supposed to > work? It's not supposed to, but at that point it's the least of our worries. The application no longer has a GUI, so it can't display anything anyway for the user. If it crashes, that's fine: it'll just be one more core file that your system will capture, after X's. The worst case scenario is if it deadlocks, but systemd will probably kill it anyway as the user session is exiting. > I wonder if that explains why I sometimes see evidence of Qt applications > that crashed after an X server went down. It could. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
