Always reset the file descriptor to -1, even if FlushWriteBuffer or
RawLoggingCloseFile fails.
Bug: 1431760
Change-Id: I193f526d65f477bba002dd9faf68996020e48a3b
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/4406657
Reviewed-by: Ben Hamilton <benhamilton@google.com>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')
Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
Adds a 4K buffer to the intermediate dump writer. Aside from the final
flush, only write in multiples of 4K. This saves between 30ms and 50ms
on an iPhone 12 Pro.
Change-Id: Icc4b222477bd91fd6952c7cf43b105e1f7a50adb
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3764243
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Adds a new IOSIntermediateDumpWriter::AddPropertyCString method which
takes an address to a cstring of unknown length and page-by-page
searches for a NUL-byte terminator.
This is necessary because currently WriteModuleInfo calls strlen
directly on the dyld and module filePath without first using vm_read.
On iOS14 this occasionally crashes, and is generally unwise. Instead,
use AddPropertyCString.
This patch also removes WriteDyldErrorStringAnnotation, as it's no
longer used going forward with iOS 15.
Bug: 1332862
Change-Id: I3801693bc39259a0127e5175dccf286a1cd97ba7
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3689516
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
IOSIntermediateDumpWriter::Close() is intended to close the FD opened
by the in-process handler.
Currently, InProcessHandler::ScopedLockedWriter::~ScopedLockedWriter() does invoke IOSIntermediateDumpWriter::Close().
However, InProcessHandler::Initialize() invokes the utility CreateWriterWithPath() which directly creates an IOSIntermediateDumpWriter. It neither uses ScopedLockedWriter nor invokes Close().
This fixes the issue by:
1) Making IOSIntermediateDumpWriter::~IOSIntermediateDumpWriter() DCHECK() that it's closed
2) Calling IOSIntermediateDumpWriter::Close() from InProcessHandler::~InProcessHandler() and from test files
Change-Id: Ibfede0a3d2aeac948c7ff3d56445e13d1a4028b5
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3648710
Commit-Queue: Justin Cohen <justincohen@chromium.org>
Reviewed-by: Justin Cohen <justincohen@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>
Due to the limitations of in-process handling, an intermediate dump file
is written during exceptions. The data is streamed to a file using only
in-process safe methods. The file format is similar to binary JSON,
supporting keyed properties, maps and arrays.
- Property [key:int, length:int, value:intarray]
- StartMap [key:int], followed by repeating Properties until EndMap
- StartArray [key:int], followed by repeating Maps until EndArray
- EndMap, EndArray, EndDocument
Similar to JSON, maps can contain other maps, arrays and properties.
Once loaded, the binary file is read into a set of data structures that
expose the data, maps and arrays.
Bug: crashpad: 31
Change-Id: I43a19204935303afd753c8c7090c54099634ccd6
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/2870807
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Justin Cohen <justincohen@chromium.org>
