The result could be worse.
If for example Unity8/Mir crashes, then while apport does
its business
the shell isn't available (obviously, as it's just
crashed) and
doesn't restart until after apport is done. This likely
results in the
user seeing longer periods of "lock up" and will more
likely reboot
the device (the only remedial measure they can take)
almost certainly
resulting in an unusable crash dump, leading to us having
no way to
determine the reason for the initial crash.
I think we should at the very least warn the user that the phone
is uploading crash reports or generating core dumps, so that he at
least knows we're slowing down the system on purpose.
I completely disagree. This is a technical detail that I believe
should be hidden from the user. Your average user will have no clue
what a crash report is. I would say that if we can't actually report a
crash in the background without taking up all of the spare CPU cycles,
then this process is broken. Perhaps apport just isn't suited for
mobile yet and needs to be fixed so that it doesn't peg the CPU and to
popey's feedback, doesn't block the shell from starting again until
after apport has finished. That would be the ideal user interaction -
crash reports just happen in the background and the user can't tell
performance-wise that it's even occurring.
Jim
