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 <aa...@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 >
