Skip to content

Change handling of recursive/concurrent crashes

Jiří Paleček requested to merge jpalecek/kcrash:recurrent-crashes into master

This is a trickier change, so I created an extra merge request for it.

The problem it tries to solve is that when an app crashes and immediately crashes again (in a different thread, perhaps), KCrash doesn't have the opportunity to do any of its business, ie. doesn't restart the app or show drkonqi. The reason for this is not that the second signal immediately shuts down the executable, but rather that it causes recursion to the signal handler which will interfere with crashRecursionCounter and cause the first handler to skip some of the stages.

The solution for this is to break the crashRecursionCounter mechanism to 3:

  • one, have a set of flags that get set on each of the stages of crashing, so that each of the stages run once
  • two, retain a recursion counter just in case of a runaway recursion
  • and maintain the thread which is crashing, the other threads should just wait except in case of a SIGALRM

Other changes are:

  • introduce WaitAndExitHandler, which makes it possible to wait for the same process in multiple threads through a global WaitAndExitHandler object
  • mostly indentation changes to other code (due to differently placed ifs etc.)
Edited by Jiří Paleček

Merge request reports