Stop the prune thread and the upload thread when moving to the
inactive/background state. This will reduce the number of 0xdead10cc
system kills from having a file lock during iOS suspend.
Wait to start the prune thread when the application is active.
Otherwise, for iOS prewarmed applications, the prune thread will
regularly start when the application is foregrounded for the first
time when the user intentionally runs the app.
It's still possible for either the prune thread or the upload thread to
have a file lock during iOS suspend, such as when a task started in the
foreground and does not complete in time for suspension. Future work
should include considering BackgroundTasks and/or NSURLSessions, which
can more safely run in the background.
Bug: crashpad: 400
Change-Id: Ic7d4687eb795fe585327f128aa84a5928141f4a9
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3517967
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
This will prune the database on a daily basis, in accordance with the
specified condition. This will also unlock any leftover intermediate
dump files.
Bug: crashpad:31
Change-Id: I229f8b8006b44d31062fbf73bb9d316d69ab2dcf
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3231618
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Instead use a custom mechanism based on the filename. Rather than a
filename of <uuid>, instead name the file <bundle-id>|<uuid>[.locked].
A locked file will have the optional .locked extension. Files can be
unlocked after writing an intermediate dump, or during initialization by
looking for matching bundle-ids.
Clients that call ProcessIntermediateDumps() will clean up any leftover
locked intermediate dumps. Clients that never call
ProcessIntermediateDumps, such as extensions that leave this up to the
main application, will be cleaned up in a followup change.
Bug: crashpad:31
Change-Id: Icd4aaa3b79351870fbe9b8463cfbdf7cff7d5f87
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3229429
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Rohit Rao <rohitrao@chromium.org>
Also fixes a usage of ->assign in the class which will be unsafe to use.
Bug: crashpad:31
Change-Id: I434df35b0669dde2323817f3c0cef1727926c85f
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2650088
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Use SIMULATOR_MODEL_IDENTIFIER to get the equivalent device model.
Bug: crashpad:31
Change-Id: I17950d77c214533614781a5ca41170d6c3a77ae3
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2726978
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
Fixes the chromium presubmit error for UTF8String:
The use of -[NSString UTF8String] is dangerous as it can return null
even if |canBeConvertedToEncoding:NSUTF8StringEncoding| returns YES.
Please use |SysNSStringToUTF8| instead.
Bug: crashpad:31
Change-Id: Iaf939012ea9d342f6a01af58119cef962319aefe
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2119613
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Gather most of the necessary information for the system snapshot.
Note that:
- The 'capture' portion of this CL will be moved out of the snapshot
interface and into a separate in-process dump to disk location.
- All of the pointer dereferences need to be wrapped in vm_read.
- The read-fast-and-dump logic in thread_snapshot may end up in a
different file completely, but until we pick a
serialization/deserialization method, keep it as-is.
Bug: crashpad:31
Change-Id: Iac82491fdb4a823163f02149f52a1e18e26fa9de
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2090173
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
