KCrash crash racing

[Harald Sitter]

On Mon, Aug 5, 2019 at 10:58 PM Albert Astals Cid <aacid at kde.org> wrote:
> > I am fairly out of ideas :/
>
> Tried looking at what breakpad does?

Breakpad does mostly what we do, technically, functionally it's not an
"interactive" crash report while drkonqi is.

Our simplified process:
crash -> handler -> cleanup (close fds) -> possibly auto-restart a new
fork of the proc -> start drkonqi -> wait for drkonqi to finish (may
be seconds or hours because it is interactive) -> re-raise signal to
dump core if there is a core pattern handlern.

Breakpad's:
crash -> handler -> clone() a child that dumps the core of the parent
to a file (IIRC) -> wait for child to finish (takes as long as the
dumping takes) -> re-raise signal to dump core if there is a core -> I
think at this point the application developer can choose to further
catch the signal and auto-restart.

The important difference is that with breakpad you know it will take a
relatively small amount of time for the dump to be finished, with
drkonqi we don't know that and it is (I presume) why we auto-restart
early. And conversely if we delayed the restart (and thus didn't need
to close the fds early) the user wouldn't have a plasmashell until
after they dealt with drkonqi somehow.

Now, perhaps the reasonable solution here is to make drkonqi
non-interactive (i.e. make it grab a dump or whatever and then
immediately return to kcrash for possible restarting). I fear that
also isn't too straight forward either.

HS