Crash through D-Bus calls

Years ago, there was a blog on the planet with the title “How to crash (almost) every Qt/KDE Application and how to fix it“. In short, if you are showing a dialog, KWin prevents you from closing the application by clicking on the close button in the window decoration. However, through D-Bus, you can still quit the application. A solution was also provided: Use a guarded pointer to create the dialog.While this fixes the issue, it looks like fixing the blame, and not the real issue. Stricktly speaking, even the Qt documentation would be wrong then.

Searching for ‘Accepted’ on lxr.kde.org shows lots of dialogs that lead to possible crashes. I wonder whether developers are really aware of this crash? Even if we took care of this issue as proposed, it’s just a matter of time until dialogs are created the `wrong’ way again (do we have krazy checks for that?). In Kate, no one took care of this situation, meaning that you can indeed crash the application through D-Bus.

Is there a better way to fix this?

8 thoughts on “Crash through D-Bus calls”

  1. It’s not just Dialogs – it’s anything that starts another exec() loop.

    This includes nepomuk sync() queries, and QProcess::waitForFinished();

    Both of these are naughty to do anyway as they block the GUI.

      1. Is there a way to fix the quit method that is called over D-Bus? It should probably ignore the call when a dialog is open.

        Does Qt keep track of event loops?

    1. Is there a way to to filter on Krazy output. Maybe we could just make a big list of them, and fix them all.

  2. Seems to me the proper fix is to make whatever quit method ends up called from dbus safe, by somehow forcing all nested events loops to break/return, and then quit.

Leave a Reply