I have a proposal to make things a bit more robust:

0/ Change crash report producers to create new files rather than
overwriting the content of existing ones.

1/ When starting the GUI process, we open the crash file and take out a
lock on it. If the lock is already held, we simply skip the file.

2/ When requiring more information (assuming it's done via spawning a
new process, which I believe is the case) we pass in the FD as input
(rather than relying on the filename as it might have been overwritten
by another crash), and a hidden temporary file as output FD.

3a/ If the user wants to upload, we link the output FD to the .upload
filename (so that we're sure that's actually what they wanted to be
uploaded, again in case of overwrite by subsequent crash)

3b/ If they want to abort, we link the output FD (or, if that one is
missing, the original crash FD) to the .seen filename.

4/ We unlink the crash FD from the .crash filename.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2087535

Title:
  Apport GUI triggering is very fragile

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/2087535/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to