• Crash through D-Bus calls

    by  • April 6, 2012 • Developers • 8 Comments

    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?

    About

    Dominik is a PhD student at the Control Theory and Robotics Lab, TU Darmstadt, as part of the Research Training Group GKMM (GRK1362). My research focuses on state estimation in distributed systems. As hobby, I contribute to the KDE project and work on the Kate application and editor component.

    http://www.kate-editor.org

    8 Responses to Crash through D-Bus calls

    1. April 6, 2012 at 15:05

      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.

      • April 6, 2012 at 15:13

        Right, that was mentioned in the linked blog as well. Interesting to see that Qt/KDE is kind of “broken by design” in this case.

        • Christian
          April 6, 2012 at 18:53

          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?

    2. Andras
      April 6, 2012 at 19:02

      I doubt you can do anything. The best is to document this properly.

    3. Peter Grasch
      April 6, 2012 at 19:19

      Yes, there’s a krazy check for that (“crashy”).

      • David Edmundson
        April 7, 2012 at 02:33

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

    4. Pedro Alves
      April 7, 2012 at 00:18

      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.