This more-natural spelling doesn’t require Crashpad developers to have
to remember anything special when writing code in Crashpad. It’s easier
to grep for and it’s easier to remove the “compat” part when pre-C++11
libraries are no longer relevant.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1513573005 .
Fixes two incorrect usages of ssize_t/off_t being implicitly converted
to bool. As such, I think it's worth the cost of the additional !! on
BOOL returning Win32 functions.
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1408123006 .
I’ve accidentally created Crashpad databases when running
crashpad_database_util by mistyping the argument to --database. Typical
users of crashpad_database_util probably don’t want the database to be
created.
This adds a new --create option to crashpad_database_util that is
required to get it to create a database. If not present, a database will
not be created if it does not already exist.
TEST=crashpad_client_test CrashReportDatabaseTest.*
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/1395653002 .
This resolves some left-behind TODOs referring to a closed bug. It looks
like this should have worked since dfaa25af4929.
BUG=crashpad:13
TEST=crashpad_snapshot_test CrashReportDatabaseTest.*
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1391993002 .
- Add public domain getopt implementation to third_party.
- Add timegm to compat/win.
- Add stub of strptime to compat/win.
Requires https://codereview.chromium.org/1119173003/ and
https://codereview.chromium.org/1117013006/.
Rather than working in wchar_t everywhere on Windows, convert
UTF16 command line arguments in wmain to UTF8, work primarily
in UTF8, and convert back when necessary to UTF16 for base::FilePath.
This avoids the need to genericize over all the standard C string
functions, getopt, etc. while still handling non-ASCII properly.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1119783005
At the moment the LOGs print something unhelpful like:
[19912:21888:20150501,145958.098:ERROR file_io_win.cc:122] CreateFile 000000C9F8FDE7F0: The system cannot find the file specified. (0x2)
(where the hex string ought to be a file name)
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1117393002
The new call is also used in
CrashReportDatabaseWin::PrepareNewCrashReport(). Previously, that method
used the UUID::InitializeFromBytes() constructor. That actually caused
various fields of the UUID to be byte-swapped so that the ::UUID and
crashpad::UUID would be different UUIDs. Although a UUID is mostly
random, the version field in data_3 is used as a namespace and should be
4 for random UUIDs, and this was not the case under swapping.
TEST=crashpad_util_test UUID.FromSystem
BUG=crashpad:1
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1004913004
Now that Chrome’s about:crashes displays the crash report UUID, I wanted
to add it to the minidump. In the future, we may be able to index these
on the server. This will also help identify dumps that correspond to the
same event once we’re equipped to convert between different formats.
Ideally, this new field is populated with the same UUID used locally in
the crash report database. To make this work,
CrashReportDatabase::NewReport must carry the UUID. This was actually
part of CrashReportDatabaseWin’s private extension to NewReport, so that
extension subclass can now be cleaned up.
TEST=crashpad_minidump_test MinidumpCrashpadInfoWriter.*,
crashpad_client_test CrashReportDatabaseTest.NewCrashReport
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1000263003
Rather than accepting the path to the database’s parent directory, this
now accepts the path to the database itself. Using the parent directory
proved cumbersome in practice. When testing crashpad_handler with a
variety of databases, it is useful to be able to specify
--database=/tmp/crashpad_database, --database=/tmp/crashpad_database_2,
etc. The old interface required that these directories be created as a
separate step, and would put the actual database at
/tmp/crashpad_database/Crashpad. This was contrary to the operation of
most tools and interfaces, which would only require that /tmp exist and
would put the database at /tmp/crashpad_database.
TEST=crashpad_client_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/991393002
This is only implemented for CrashReportDatabaseMac, because
CrashReportDatabaseWin does not currently have a Settings object. See
bug crashpad:13.
TEST=crashpad_client_test CrashReportDatabaseTest.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/995853003
Mostly size_t <-> unsigned int warnings, but I also had a mistake in
PROCESS_BASIC_INFORMATION, the pids are 32-on-32 and 64-on-64.
The Windows build is still x86 until https://codereview.chromium.org/981333002/.
I don't think I'll bother maintaining the x86 build for now, though we will probably
need it for x86 OSs in the future. It should be straightforward to revive it once we
need it, and have bots to support it.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/983103004
A couple of the problems related to not having a C++11 library:
- You can’t put const elements into a std::vector<>, so
CrashReportDatabase::GetPendingReports() and
CrashReportDatabase::GetCompletedReports() need to change. There was
no data-safety benefit to const elements.
- std::string::pop_back() does not exist, another mechanism must be
used to trim strings in BreakpadHTTPFormParametersFromMinidump().
One relates to a feature that does not exist in 10.6:
- The O_CLOEXEC flag to open() was introduced in 10.7. Although it
would be possible to use fcntl(..., F_SETFD, FD_CLOEXEC) on 10.6, the
O_CLOEXEC behavior is just removed from
CrashReportDatabaseMac::ObtainReportLock(), in line with other open()
calls in Crashpad.
And one was a real bug:
- #define __STDC_FORMAT_MACROS before #including <inttypes.h> to get
format macros like SCNx32, used in UUID::InitializeFromString().
TEST=* (gyp_crashpad.py -Dmac_sdk=10.6 -Dmac_deployment_target=10.6)
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/987693004
As there are no extended file attributes available on all Windows file
systems (NTFS supports alternate data streams, but Chrome still supports
running on FAT), instead of using metadata attached to the file, metadata
is stored separately in a simple record-based file and keyed by UUID.
Initially, I attempted a metadata file beside each report, each locked
separately more closely mirroring the Mac implementation. But given the
expected number of of active reports (in the 10s to 100s range?) and the
size of the metadata for each, simply storing it all in one file is much
less complicated when considering error situations.
If the serialization/deserialization becomes a measurable problem, it
could be optimized at some complexity by reading/writing only as
necessary, or optimizing the storage.
R=mark@chromium.org, rsesek@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/867363003