KCrash crash racing

[Albert Astals Cid]

El dimecres, 7 d’agost de 2019, a les 16:36:31 CEST, Harald Sitter va escriure:
> 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.

Does this solve the racing issue? Or do they have the same problem as we do?

Cheers,
  Albert

> 
> 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
>