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 .
MEMORY_BASIC_INFORMATION64 specifies an alignment of 16, but the
standard allocator used by containers doesn't honor this. Although 16
is the default alignment size used on Windows for x86_64, it's not for
32-bit x86. clang assumed that the alignment of the structure was as
declared, and used an SSE load sequence that required this alignment.
AlignedAllocator is a replacement for std::allocator that allows the
alignment to be specified. AlignedVector is an std::vector<> that uses
AlignedAllocator instead of std::allocator.
BUG=chromium:564691
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1498133002 .
This unifies several things that used a 16-character random string, and
a few other users of random identifiers where it also made sense to use
a 16-character random string.
TEST=crashpad_util_test RandomString.RandomString
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1451793002 .
This consolidates all of the twisted casts and comments that discuss how
HANDLEs are really only 32 bits wide even in 64-bit processes on 64-bit
operating systems into a single location.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1422503015 .
I thought I had confirmed that this still allocated and ignored the flag
on older OSs, but I must have not had the PLOG active yet? I'm not sure
what I did. (I might try to blame VMware as it has an annoying habit of
caching old binaries when you use it's "Shared Folders" feature to point
at the dev machine's build dir.)
I confirmed that it does work on Win8 and Win10 but doesn't on Win XP
and Win 7.
R=mark@chromium.org
BUG=crashpad:52
Review URL: https://codereview.chromium.org/1405243002 .
PROCESS_ALL_ACCESS was changed in later SDKs and the newer value fails
when run on XP with ERROR_ACCESS_DENIED. Use the old value to maintain
compatibility with XP.
R=mark@chromium.org
BUG=crashpad:50
Review URL: https://codereview.chromium.org/1337133002 .
This replaces the registration server, and adds dispatch to a delegate
on crash requests.
(As you are already aware) we went around in circles on trying to come
up with a slightly-too-fancy threading design. All of them seemed to
have problems when it comes to out of order events, and orderly
shutdown, so I've gone back to something not-too-fancy.
Two named pipe instances (that clients connect to) are created. These
are used only for registration (which should take <1ms), so 2 should be
sufficient to avoid any waits. When a client registers, we duplicate
an event to it, which is used to signal when it wants a dump taken.
The server registers threadpool waits on that event, and also on the
process handle (which will be signalled when the client process exits).
These requests (in particular the taking of the dump) are serviced
on the threadpool, which avoids us needing to manage those threads,
but still allows parallelism in taking dumps. On process termination,
we use an IO Completion Port to post a message back to the main thread
to request cleanup. This complexity is necessary so that we can
unregister the threadpool waits without being on the threadpool, which
we need to do synchronously so that we can be sure that no further
callbacks will execute (and expect to have the client data around
still).
In a followup, I will readd support for DumpWithoutCrashing -- I don't
think it will be too difficult now that we have an orderly way to
clean up client records in the server.
R=cpu@chromium.org, mark@chromium.org, jschuh@chromium.org
BUG=crashpad:1,crashpad:45
Review URL: https://codereview.chromium.org/1301853002 .
The main goal was to get the beginnings of module iteration and retrieval
of CrashpadInfo in snapshot. The main change for that is to move
crashpad_info_client_options[_test] down out of mac/.
This also requires adding some of the supporting code of snapshot in
ProcessReaderWin, ProcessSnapshotWin, and ModuleSnapshotWin. These are
partially copied from Mac or stubbed out with lots of TODO annotations.
This is a bit unfortunate, but seemed like the most productive way to
make progress incrementally. That is, it's mostly placeholder at the
moment, but hopefully has the right shape for things to come.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1052813002
This adds IsExceptionNonfatalResource() and its test, and uses it in
crashpad_handler. When non-fatal resource exceptions are encountered, no
crash report is generated. crashpad_handler swallows these exceptions.
Alternatively, it could allow them to be sent to the system’s host-level
resource exception handler, normally com.apple.ReportCrash.root, which
would allow them to be processed in the same way as when Crashpad is not
in use. I’m not sure which option is better. I chose to swallow them
because there doesn’t appear to be much value in letting
com.apple.ReportCrash.root and spindump look at them.
This also moves ExcCrashRecoverOriginalException() to the new file as a
sibling of IsExceptionNonfatalResource(). This provides better
organization.
BUG=crashpad:35, chromium:474163, chromium:474326
TEST=crashpad_util_test ExceptionTypes.IsExceptionNonfatalResource
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1066243002
In a future change, crashpad_util_test_lib will gain a dependency on
crashpad_client. This would violate GYP’s prohibition on circular
dependencies between .gyp files, although there would be no circular
relationship between the targets themselves. To overcome this problem,
all test-related targets are moved into their own first-class .gyp
files.
BUG=crashpad:33
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1045173004
Add MapInsertOrReplace<>() to insert a key-value pair into a map if the
key is not already present, or replace the existing value for key if the
key is present. The original value can optionally be returned to the
caller in this case.
Map insertions now use either MapInsertOrReplace<>() or
std::map<>::insert() directly.
Use MapInsertOrReplace<>() when the map should be updated to contain a
mapping from a key to a value regardless of whether the key is already
present.
Use std::map<>::insert() to insert a mapping from a key to a value
without replacing any existing mapping from a key, if present. If it is
important to know whether an existing mapping from a key was present,
use the returned std::pair<>.second. If it is important to know the
existing value, use the returned std::pair<>.first->second.
This change has a slight positive impact on performance.
TEST=crashpad_util_test MapInsert.MapInsertOrReplace and others
BUG=
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1044273002
This updates mini_chromium to 91ea4908ffd74d9c886bd2f8ccbfae6d31c499af.
The last five commits listed here are required to support this change.
The mini_chromium update includes:
c1745a924c5c Fix paths to atomicops files in base.gyp from 2f02dcc73536
108e9247189c Add #include of <unistd.h> to close_nocancel.cc
6e4f98a9edf8 Add logging::SetLogMessageHandler()
4063fcb8f460 Add base::ThreadLocalStorage
4870f18a33a6 Add base::LazyInstance
0d31b1f3a289 Fix base/memory/aligned_memory.h for MSVC
91ea4908ffd7 base/logging.h: DCHECK() should always reference its
condition
BUG=crashpad:26
TEST=crashpad_util_test ThreadLogMessages.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1041643003
Towards removing use of open() with O_EXLOCK/O_SHLOCK in code
used on non-BSD.
Adds simple Thread abstraction to util/test.
Includes mini_chromium roll with:
56dd2883170d0df0ec89af0e7862af3f9aaa9be6 Fix import of atomicops for Windows
886592fd6677615c54c4156bb2f2edb5d547ba6c Export SystemErrorCodeToString
R=mark@chromium.org, rsesek@chromium.org
BUG=crashpad:1, crashpad:13
Review URL: https://codereview.chromium.org/1001673002
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
This makes it easier for clients to start the Crashpad handler, instead
of requiring them to know how to construct arguments for the handler
themselves. Note in the TEST that -a is no longer required.
TEST=run_with_crashpad --handler crashpad_handler \
--database=/tmp/crashpad_db \
--url=https://clients2.google.com/cr/staging_report \
--annotation=prod=crashpad \
--annotation=ver=0.7.0 \
crashy_program
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1001993002
origin.
This adds AuditPIDFromMachMessageTrailer() to get the process ID of a
Mach message’s sender. Exception messages are considered suspicious when
not sent by the kernel or the exception process.
TEST=crashpad_util_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1001943002
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
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
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
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
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
- Various "FD" to "Handle"
- Existing Multiprocess implementation moves to _posix.
- Stub implementation for _win.
At the moment, multiprocess_exec_win.cc contains implementations of both
Multiprocess methods and MultiprocessExec functions. This will need more
work in the future, but reflects the idea that all tests should be in
terms of MultiprocessExec eventually.
Currently, this works sufficiently to have util_test succeed (including
multiprocess_exec_test, and the recently ported HTTPTransport tests.)
R=mark@chromium.org
BUG=crashpad:1, crashpad:7
Review URL: https://codereview.chromium.org/880763002
This function will be useful in upcoming non-test code. Because the
first Crashpad client that wants a Crashpad handler will now be
responsible for starting the handler process, this will prevent file
descriptors from leaking to the handler process.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/819483002
There will be no reason to leave the handler process connected to its
invoker’s stdin or stdout.
On the other hand, I’m currently leaving it connected to the original
and stderr, as these may be useful for diagnostics.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/818573002
Rename fd_io to file_io, and ReadFD to ReadFile, etc.
file_io.cc is the higher level versions that call the basic ReadFile/WriteFile
and then file_io_posix.cc and file_io_win.cc are the implementations of
those functions.
The Windows path is as yet untested, lacking the ability to link the test binary.
R=cpu@chromium.org, mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/811823003
A subsequent change will add MachMessageWithDeadline(), a mach_msg()
wrapper. Conceptually, it makes sense to include that function in this
file family. Since this file family now contains a mach_msg() wrapper,
it makes sense to rename it mach_message and lose the _util suffix.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/772133004
ChildPortHandshake is the most generic system yet to allow child
processes to provide their parents with Mach rights. These are
ordinarily expected to be send rights to the children’s own task ports,
or send rights to servers that the children hold receive rights to.
This updates DEPS to pull mini_chromium 1d3523dbda93, which includes
base::mac::ScopedMachPortSet.
TEST=util_test ChildPortHandshake.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/756603003
the child_port subsystem.
Common routines shared with the ExcServer family of classes have been
moved to a new file, where they can be shared between different
MachMessageServer::Interface implementations.
TEST=util_test ChildPortServer.*:MachMessageUtil.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/754123002
DropPrivileges() is used in exception_port_tool, so that when it is
installed as a setuid executable, it only uses elevated privileges to
obtain a task port for its -p option, and then relinquishes those
privileges.
It is difficult to provide a test for this function, because it must be
running setuid or setgid in order to do anything interesting. However,
the function contains its own CHECKs to verify that it behaves properly.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/727053002
This also transitions exception_port_tool to use TaskForPID(), so that
it can be safely used as a setuid executable without giving permission
to operate on any process on the system.
It is difficult to provide a test for this function, because it must be
running setuid root in order to do anything interesting.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/728973002
Also, move ProcessArgumentsForPID() into ProcessInfo.
This change prepares for a TaskForPID() implementation that’s capable of
operating correctly in a setuid root executable. TaskForPID() belongs in
util/mach, but for its permission checks, it must access some process
properties that were previously fetched by ProcessReader in snapshot.
util can’t depend on snapshot. The generic util-safe process information
bits (Is64Bit(), ProcessID(), ParentProcessID(), and StartTime()) are
moved from ProcessReader to ProcessInfo (in util), where the current
ProcessReader can use it (as it’s OK for snapshot to depend on util),
and the future TaskForPID() in util can also use it. ProcessInfo also
contains other methods that TaskForPID() will use, providing access to
the credentials that the target process holds. ProcessArgumentsForPID()
is related, and is also now a part of ProcessInfo.
TEST=snapshot_test, util_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/727973002
7dda7b322881 accidentally moved the libbsm.dylib dependency from
util_test_lib to util_test. It is only used by
test/mac/mach_multiprocess.cc in util_test_lib.
Meanwhile, util_test should link against Foundation.framework, which is
used by three tests in util/mac: launchd_test.mm, mac_util_test.mm, and
service_management_test.mm.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/612923004
This includes ClockMonotonicNanoseconds() and SleepNanoseconds().
SleepNanoseconds() is like base::PlatformThread::Sleep(), but
PlatformThread is not in mini_chromium and I’m not keen on adding it
because I’m not sold on the interface. I’m not convinced Sleep() belongs
there, and I don’t want to have to bring all of base::Time* along for
the ride.
TEST=util_test Clock.*:MachMessageServer.*:ServiceManagement.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/597533002
This will be used in the upcoming Minidump context structures.
This also updates mini_chromium to ba9b15f1b6a7 to pick up:
ba9b15f1b6a7 Make bit_cast available in C++11 mode.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/583283003
This reverts commit 63fd3ae47d2513ef4390c3d8c0dde3fa95152480.
SMJobRemove() still performs a 1-second sleep() when its |wait|
parameter is true. Radar 18398683 is filed. In the mean time, the
launchd-based implementation of these functions does not have this
undesirable property.
The comments have been revised to not reflect operating systems before
Mac OS X 10.6. Comments describing bugs in earlier 10.10 seeds that have
since been fixed have been removed.
TEST=util_test Launchd.*:ServiceManagement.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/579083003
This includes the functions ExceptionBehaviorHasState(),
ExceptionBehaviorHasIdentity(),
ExceptionBehaviorHasMachExceptionCodes(), and ExceptionBehaviorBasic().
TEST=util_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/565793005
This also puts kMachExceptionCodes into mach_extensions.h, because a
form of MACH_EXCEPTION_CODES that’s the right type
(exception_behavior_t) has now shown its use in more than one file.
TEST=util_test ExcClientVariants.UniversalExceptionRaise
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/567283002
This includes the StringToNumber() function, both int and unsigned int variants.
Similar functionality is available in base, but it is unsuitable for
applications where a number’s base may be determined based on an "0x" or
"0X" prefix (hexadecimal) or an "0" prefix (octal).
TEST=util_test StringNumberConversion.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/557033002
MachMessageServer is much like mach_msg_server() and
mach_msg_server_once(), but with a C++ interface and with a number of
deficiencies corrected.
TEST=util_test MachMessageServer.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/544393002
mach_exc is necessary because libSystem doesn’t contain this at all. exc
is necessary too, however: the copy in libSystem relies on the server
callbacks being externally defined symbols, which is cheesey.
Additionally, some Crashpad code wants to call internal validation
(“check”) routines that are not normally accessible to outside callers
via the copy of exc in libSystem, but they are made accessible here by
processing mig’s output in this Python script.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/541213002
This is part of a family of classes whose chief entry point is
MachOImageReader. MachOImageReader depends on this class to read
segments, so this one is landing first. The bulk of this class will be
tested as part of MachOImageReader.
TEST=util_test MachOImageSegmentReader.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/516983003
