Change Details

Observed with a crashing KDevelop: If the QApplication is destructed after cleanup of the DrKonqi backend, somehow a DrKonqi-thread of the QDBusConnection may be blocked by the debuggee (poll() being stuck according to strace). Since DrKonqi then cannot quit, KCrash continues waiting, leading to a deadlock. The situation may be disentangled by externally sending SIGSTOP to the debuggee. Cleaning up the QApplication first and afterwards the backend omits the deadlock.

Observed with a crashing KDevelop: DrKonqi may be blocked by a thread in the debuggee if the QApplication is destructed after cleanup of the DrKonqi backend. The backend sends SIGCONT to the debuggee upon destruction. Since DrKonqi then cannot quit, KCrash continues waiting, leading to a deadlock. The situation may be disentangled by externally sending SIGSTOP to the debuggee or waiting with the SIGCONT signal. Cleaning up the QApplication first and afterwards the backend omits the deadlock.

Observed with a crashing KDevelop: If the QApplication is destructed after cleanup oDrKonqi may be blocked by a thread in the debuggee if the DrKonqi backend, somehow a DrKonqi-threadQApplication is destructed after cleanup of the QDBusConnection may beDrKonqi backend. blocked by the debuggee (poll() being stuck according to strace).The backend sends SIGCONT to the debuggee upon destruction. Since DrKonqi then cannot quit, KCrash continues waiting, leading to a deadlock. The situation may be disentangled by externally sending SIGSTOP to the debuggee or waiting with the SIGCONT signal. Cleaning up the QApplication first and afterwards the backend omits the deadlock.