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