disabled.
ClientInfo::set_system_crash_reporter_forwarding() can be used to
disable forwarding. The first module that is found with a non-default
value in this field will dictate whether forwarding is enabled or
disabled. It is possible to enable or disable reporting with this call,
as well as reset it to default, which will allow later modules a chance
to influence the behavior.
ClientInfo::set_crashpad_handler_behavior() is also provided, which can
be used to disable Crashpad’s handling of the exception. Most users
should not call this, but should use Settings::SetUploadsEnabled()
instead.
TEST=crashpad_snapshot_test \
CrashpadInfoClientOptions.*:MachOImageReader.Self_DyldImages; \
run_with_crashpad --handler crashpad_handler \
-a --database=/tmp/crashpad_db \
-a --url=https://clients2.google.com/cr/staging_report \
-a --annotation=prod=crashpad \
-a --annotation=ver=0.7.0 \
crashy_program
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/997713002
NSInputStream requires overriding and implementing private methods in order to
use it with NSURLConnection [1]. It is cleaner to use the private but stable
and open source CFStreamAbstract.h header from CF-Lite to implement a
CFReadStream. Since CFReadStream is toll-free bridged to NSInputStream, the
remainder of the HTTPTransport code can remain unchanged.
[1] http://lists.apple.com/archives/macnetworkprog/2007/May/msg00055.html
BUG=crashpad:15
R=mark@chromium.org
Review URL: https://codereview.chromium.org/993413003
Child exits were using exit(), which caused crashes on 10.10 for
Multiprocess-based tests that ran after HTTPTransport tests. The crashes
occurred while running exit-time destructors. exit() was never correct
in this situation, this should have used _exit() all along.
TEST=crashpad_util_test
BUG=crashpad:17
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1000653002
upload attempts to no more than 1 per hour.
The rate limiting is simplistic but duplicates the existing Breakpad
client’s behavior, and is suitable for the time being.
TEST=run_with_crashpad --handler crashpad_handler \
-a --database=/tmp/crashpad_db \
-a --url=https://clients2.google.com/cr/staging_report \
-a --annotation=prod=crashpad \
-a --annotation=ver=0.7.0 \
crashy_program
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/992303002
I don’t want to call it 1.0 yet because the Windows client isn’t done
and there’s no processor yet, but I do want to bump the number at around
the time of the initial Mac client Chromium integration (now).
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/998653002
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 makes it possible to #include "client/settings.h" for the interface
even on Windows. Although Settings is not currently implemented on
Windows (bug crashpad:13), it’s easier to have the interface declaration
available without having to have it be guarded.
TEST=crashpad_client_test SettingsTest.*
BUG=
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/987383002
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
optimization.
Newer versions of clang (in this case, trunk r231191) can see through
the pointless division by zero and optimize it away. This caused the
test to hang in release mode.
A 50ms timeout is added to each test to transform the hang into a
failure. The test was split into 12 tests to provide better feedback and
control.
To fix the bug, the division by zero is replaced by __builtin_trap().
TEST=crashpad_util_test ExceptionPorts.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/993613004
This only works 64->64, 32->32, and 64->32. We shouldn't have a
need for 32->64. It will also currently not work if the crash service
is running on Wow64 itself (that is, 32->32, but on an x64 OS). We
should also be able to avoid needing that.
Primarily, this change templatizes the winternl.h process structure
types on word size, so the PEB can be read in a foreign bitsize process.
This also happens to resolve using void* as pointer values into foreign
processes, as they're now all either DWORD or DWORD64 depending on which
traits class is used.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/981393003
Likewise for EXPECT_DEATH_CHECK() and EXPECT_DEATH().
In the in-Chromium build configured for official builds in Release mode,
CHECK() throws away its condition string and stream parameters without
ever printing them, although it still evaluates the condition and
triggers death appropriately. {ASSERT,EXPECT}_DEATH(statement, regex)
will not work correctly for any regex that attempts to match what
CHECK() prints. In these build configurations,
{ASSERT,EXPECT}_DEATH_CHECK() use a match-all regex (""). In other build
configurations, they transparently wrap {ASSERT,EXPECT}_DEATH().
BUG=crashpad:12
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/992693003
When building in the Chromium tree, this swaps out Crashpad’s copies of
mini_chromium, gtest, and gmock for the equivalents provided by
Chromium. A GYP variable, crashpad_in_chromium, is used to determine the
behavior.
gclient doesn’t sync sub-DEPS, so when doing an in-Chromium build,
Crashpad’s copies of mini_chromium, gtest, and gmock are not available.
BUG=crashpad:12
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/986033002
Test code that requires test data should call Paths::TestDataRoot() to
obtain the test data root. This will use the CRASHPAD_TEST_DATA_ROOT
environment variable if set. Otherwise, it will look for test data at
known locations relative to the executable path. If the test data is not
found in any of these locations, it falls back to using the working
directory, the same as the current behavior.
BUG=crashpad:4
TEST=crashpad_util_test Paths.TestDataRoot and others
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/992503002
gtest and gmock both rely heavily on exit-time destructors, and must
build with -Wno-exit-time-destructors to avoid these warnings.
gmock’s MOCK_METHODn() macros violate
-Wno-inconsistent-missing-override, so this warning is disabled for
direct dependents of gmock.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/984393002
nullptr ProcessReader::Module.
Prior to 64b87325b9de, the alignment problem meant that the Module for
dyld was looking at the wrong address instead of dyld’s correct load
address when a 32-bit process attempted to examine a crashing 64-bit
process. This resulted in a crash during the
MachOImageAnnotationsReader.CrashDyld test.
ProcessReader::Module pointers are permitted to be nullptr. This allows
minimal module data (its name) to be preserved even when no sense can be
made of the module based on its load address. The producer,
ProcessReader::InitializeModules(), and the non-test consumer,
ModuleSnapshotMac::Initialize(), both accept this correctly. The
producer’s documentation is updated to call this out. The ProcessReader
test is also updated to tolerate this case without crashing by adding
assertions.
TEST=snapshot_test MachOImageAnnotationsReader.*, ProcessReader.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/989713002
In Chromium, many targets are built, sharing a single output directory.
Collisions are likely. When integrating Crashpad into Chromium, the
ui/snapshot library and Crashpad’s snapshot library were found to
conflict.
This change gives most Crashpad targets a “crashpad_” prefix to avoid
conflicts. All library and test targets are given a target_name with
this prefix. Existing tools are not likely to conflict with anything
else and are not given a prefix.
BUG=crashpad:12
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/990553003
When building in the Chromium tree, chromium_code is necessary to apply
Chromium’s build/filename_rules.gypi. Crashpad’s build depends on these
rules. chromium_code also enables a high warning level, which is
desirable for Crashpad.
BUG=crashpad:12
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/986873002
A few stragglers were missing from bc401f6aac22. I really don’t know how
that’s possible, since I thought I was testing it with the correct SDK.
I guess I wasn’t.
BUG=crashpad:11
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/978883007
The 10.10 SDK deprecates <launch.h>, but this file is still useful and
is used by util/mac/launchd.* and util/mac/service_management.*. Wrap
the <launch.h> functions in versions that ignore the deprecation
warnings.
BUG=crashpad:10
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/989733003
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
This is as a precursor to ProcessReader. Some basic functionality
is included for now, with more to be added later as necessary.
The PEB code is pretty icky -- walking the doubly-linked list
in the target's address space is cumbersome. The alternative
is to use EnumProcessModules. That would work but:
1) needs different APIs for XP and Vista 64+
2) retrieves modules in memory-location order, rather than
initialization order. I felt retrieving them in initialization order
might be useful when detecting third party DLL injections. In the
end, we may want to make both orders available.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/977003003
The handler is now capable of uploading crash reports from the database.
At present, only one upload attempt is made, and the report will be
moved to “completed” in the database after the attempt, regardless of
whether it succeeded or failed.
The handler also has support to push annotations from its command line
into the process annotations map of each crash report it writes. This is
intended to set basic information about each crash report, such as the
product ID and version. Each potentially crashy process can’t be relied
on to maintain this information on their own.
With this change, Crashpad is now 100% capable of running a handler that
maintains a database and uploads crash reports to a Breakpad-type server
such that Breakpad properly interprets the reports. This is all possible
from the command line.
TEST=run_with_crashpad --handler crashpad_handler \
-a --database=/tmp/crashpad_db \
-a --url=https://clients2.google.com/cr/staging_report \
-a --annotation=prod=crashpad \
-a --annotation=ver=0.6.0 \
crashy_program
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/982613002
ProcessSnapshotMinidump.
ModuleSnapshotMinidump is currently only capable of reading module
annotations, in both vector and simple-dictionary forms. It does not
read any other module information from minidump files. These annotations
are all that are necessary to be able to upload Crashpad-produced
minidumps to Breakpad crash processor servers, because Breakpad accepts
them as HTTP POST parameters, while Crashpad places them in the minidump
file itself.
TEST=snapshot_test ProcessSnapshotMinidump.Modules
BUG=crashpad:10
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/972383002
between classic and extension structures.
Previosly, each MinidumpModuleCrashpadInfo structure contained a
minidump_module_list_index field referencing a module in the
MINIDUMP_MODULE_LIST stream by index. This layout was discovered to
cause a problem for the new minidump reader in ModuleSnapshotMinidump.
Instead, the module list index for linkage should be contained in the
MinidumpModuleCrashpadInfoList alongside the LOCATION_DESCRIPTORs
pointing to each MinidumpModuleCrashpadInfo.
The organizational difference is small, but this enables a better design
for ModuleSnapshotMinidump. When initializing a ModuleSnapshotMinidump
with the new layout, it is possible for the caller to have access to the
location descriptor for the MinidumpModuleCrashpadInfo corresponding to
a MINIDUMP_MODULE_LIST. Previously, the caller would not have had this
data without interpreting each MinidumpModuleCrashpadInfo, which
ModuleSnapshotMinidump would have to do anyway.
MinidumpModuleCrashpadInfoListWriter was the only user of
MinidumpLocationDescriptorListWriter, which is obsoleted and removed in
this change. Its functionality is moving directly into
MinidumpModuleCrashpadInfoListWriter, but it is no longer generic enough
to maintain as a distinct class.
TEST=minidump_test \
MinidumpModuleCrashpadInfoWriter.*,MinidumpCrashpadInfoWriter.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/978463003
the Snapshot family.
For the time being, only ProcessSnapshotMinidump::AnnotationsSimpleMap()
is implemented. In order to complete the initial uploader for Crashpad,
ModuleSnapshotMinidump::AnnotationsSimpleMap() is also needed, to be
accessed by ProcessSnapshotMinidump::Modules().
TEST=snapshot_test ProcessSnapshotMinidump.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/932153003
implement the new interface.
The upcoming minidump reader will get minidump data from a
FileReaderInterface. For ease of testing, a string-based implementation
is provided. There wasn’t a good reason to have a separate
StringFileReader and StringFileWriter, so I combined them into a single
StringFile.
TEST=util_test StringFile.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/936153002
Some annotations will exist at a broader scope than per-module, which is
the only place that annotations can currently be stored. The product
name and version are not under the control of any module, but are
established when the first Crashpad client establishes a handler. These
annotations will be stored in a minidump’s MinidumpCrashpadInfo
structure, which applies to the entire minidump.
Within the snapshot interface, this data is carried within the
“process” snapshot because it is the top-level structure in that family.
Note that the data may not correspond directly with a process, however.
TEST=minidump_test MinidumpCrashpadInfoWriter.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/924673003
Upload isn’t actually hooked up yet, but this establishes the upload
thread and provides all of the plumbing to process pending reports. For
the time being, SkipReportUpload() is called for all pending reports.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/918743002
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
