New issue
Advanced search Search tips

Issue 918862 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: iOS
Pri: 2
Type: Bug



Sign in to add a comment

Delete freeze report on recovery

Project Member Reported by olivierrobin@chromium.org, Jan 3

Issue description

Privacy review pointed that crash reports shoulc not be uploaded if application recovers.
Delete the files when the main thread recovers.
 
Cc: pkl@chromium.org
After POC, I think the best way to do this is to move the files on creation in another directory.
The name of the file is saved in NSUserDefault.
On recovery, the crashdump is deleted.

On next startup, if there is no newer crash report in the breakpad directory, the crash report is uploaded. Then the uploading is restarted.
This check must be done before Breakpad starts uploading (otherwhise, we can have a false negative).
Q1: the safest way is to do the check on main thread before breakpad starts uploading. It will make a blocking call on main thread to list the current files in a directory.
Is that acceptable?

Q2: As we now only upload on real UTE, we may relax some of the privacy guards (only one report per session and switch to create reports every k ms to update the stack.
WDYT?


Q1: "blocking call on main thread" sounds scary. But you are only checking the existence of *1* file with name already saved in NSUserDefault, right? If so, even though the call is synchronous, it is still finite and more or less constant.

Q2: SGTM
Q1. Not really. We need to check if another report has been created after we generated our freeze report. This basically means iterating over all reports and check creation date. If a user only uses cell data, this can be a medium-sized list.

The alternatives could be to store the number of reports present in the crash directory and only upload if there are no new crash report. Checking the number of files in directory should be fast. We would have to update this number regularly to avoid the scenario were an old report is uploaded during the freeze, and a new is generated, we miss the change of report numbers.

Other alternative would be to make this check in the watchdog thread, and only start uploading reports once this is done.
Status: Fixed (was: Started)

Sign in to add a comment