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 .
CrashReportExceptionHandler::CatchMachException() must always set a
valid new_state. Failing to do so appears to trigger corpse generation
on OS X 10.11. This is addressed by calling ExcServerCopyState().
Previously, this was not done for exceptions forwarded to the user
ReportCrash, under the apparent mistaken assumption that ReportCrash
would do it. However, ReportCrash is given copies of out-parameters like
new_state to explicitly prevent it from influencing Crashpad’s returned
state.
ExcServerSuccessfulReturnValue() must not return MACH_RCV_PORT_DIED for
an EXC_CRASH handler on OS X 10.11. This appears to trigger corpse
generation. This is addressed by always returning KERN_SUCCESS from
EXC_CRASH handlers on OS X 10.11.
This also adds generic EXC_CORPSE_NOTIFY support throughout Crashpad.
The crashpad_handler does not listen for this exception type, but it is
now possible to work with this exception type using tools like
exception_port_tool and catch_exception_tool.
BUG=crashpad:48
TEST=Crashes handled by crashpad_handler do not result in the generation
of reports in the root /Library/Logs/DiagnosticReports.
R=kerrnel@chromium.org, rsesek@chromium.org
Review URL: https://codereview.chromium.org/1305893010 .
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 .
MachOImageReader::GetCrashpadInfo() expects the CrashpadInfo struct to
be the only thing in a __DATA,__crashpad_info section, and enforces this
by checking that the section’s size matches the size declared in the
struct’s size_ field.
Under AddressSanitizer, a red zone follows the structure. While not
reflected in the size of the structure, it is reflected in the size of
the section, causing MachOImageReader::GetCrashpadInfo() to reject the
CrashpadInfo on the assumption that something else is present in the
section.
By specifying an alignment greater than the minimum red zone size of 32
bytes, red zone generation can be suppressed.
TEST=crashpad_snapshot_test
BUG=crashpad:44
R=glider@chromium.org, rsesek@chromium.org
Review URL: https://codereview.chromium.org/1296523003 .
Calling std::vector<>::operator[]() with an out-of-range index argument
is undefined behavior. In two cases, Crashpad used &v[0] in situations
where it was known that the address would not be used. These calls were
wrapped in conditions guarding against vector emptiness.
While s[0] is valid on an empty string, in two cases, Crashpad used
&s[0] as an argument to a system call that would be a no-op. These calls
were wrapped in similar conditions to avoid the system call.
The two uses of vector with undefined behavior were caught by the
following tests in crashpad_snapshot_test with
UndefinedBehaviorSanitizer:
[ RUN ] CrashpadInfoClientOptions.OneModule
/Users/mark/compilatorium/llvm.build/bin/../include/c++/v1/vector:1493:12:
runtime error: reference binding to null pointer of type
'crashpad::process_types::section'
[ OK ] CrashpadInfoClientOptions.OneModule (72 ms)
[ RUN ] ProcessSnapshotMinidump.Empty
/Users/mark/compilatorium/llvm.build/bin/../include/c++/v1/vector:1493:12:
runtime error: reference binding to null pointer of type
'MINIDUMP_DIRECTORY'
[ OK ] ProcessSnapshotMinidump.Empty (1 ms)
The Crashpad codebase was audited by searching for resize() calls and
analyzing how resized strings and vectors are used.
TEST=*
BUG=
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1283243004 .
Found by -fsanitize=undefined:
[ RUN ] Launchd.CFPropertyToLaunchData_FloatingPoint
../../../util/mac/launchd_test.mm:82:33: runtime error: value
1.79769e+308 is outside the range of representable values of type
'float'
[ OK ] Launchd.CFPropertyToLaunchData_FloatingPoint (2 ms)
TEST=crashpad_util_test Launchd.CFPropertyToLaunchData_FloatingPoint
BUG=
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1302843004 .
Chromium builds with a newer clang than the Crashpad buildbot, and it
reports:
../../../handler/crash_report_upload_thread.cc:148:16: error: 'ThreadMain' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
virtual void ThreadMain() {
^
../../../util/thread/thread.h:46:16: note: overridden virtual function is here
virtual void ThreadMain() = 0;
^
1 error generated.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1302833002 .
Under asan, there are many more instructions than without. The “nearby
PC” check is much less useful, and would likely fail.
TEST=crashpad_client_test CaptureContext.CaptureContext
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1298943003 .
While not strictly asan-related, this bug was found while running tests
under asan. Evidently, strings are pooled differently in that build
configuration.
TEST=crashpad_util_test ExceptionPorts.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1291573004 .
HTTPTransport.Upload33k failed on Windows due to WinHTTP timing out. The
test server, http_transport_test_server.py, writes the entire request to
a stdout pipe, to be received by crashpad_util_test. crashpad_util_test
is also the HTTP client, and it does not attempt to read from this pipe
until the HTTP transaction is complete. http_transport_test_server.py
must not write to stdout until the transaction is complete, otherwise,
there is a risk of deadlock if the pipe buffer fills up. The new
Upload33k test sends a large request, which was filling up the pipe
buffer on Windows.
This also adds an Upload33k_LengthUnknown test variant to exercise a
large POST when the length is not known ahead of time. This more closely
matches how Crashpad crash uploads are done on OS X.
TEST=crashpad_util_test HTTPTransport.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1286173007 .
CFStream’s CFReadStreamGetBuffer() calls the Read() callback without
initializing at_eof. The callback function is responsible for setting it
on any successful read operation. See 10.10.2 CF-1152.14/CFStream.c.
By chance, at_eof seems to always have an initial value of false on
x86_64, but true on 32-bit x86. Crashpad’s Read() callback assumed that
the initial value was always false. The discrepancy caused truncation
and possibly hangs when a 32-bit process attempted to upload a request
body larger than 32kB, the buffer size used by NSMutableURLRequest or
something between it and CFReadStream.
A new test with more than 32kB of data is added.
As discussed in:
https://groups.google.com/a/chromium.org/d/topic/crashpad-dev/Vz--qMZJRPU
TEST=crashpad_util_test HTTPTransport.Upload33k
BUG=
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1304433004 .
After 6083a2706d55, it is possible to determine the expected size of a
versioned structure such as dyld_all_image_infos. The expected size is
compared against the actual size of the structure as returned by
task_info() (TASK_DYLD_INFO).
TEST=crashpad_snapshot_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1272283004 .
Rather than declaring ExpectedSizeForVersion() for all process_types
types and providing a default NOTREACHED() implementation, this only
declares it for process_types that request it by stating
PROCESS_TYPE_STRUCT_VERSIONED() in their proctype definition. This also
allows the argument to have the correct type, matching the type of the
struct’s version field.
TEST=crashpad_snapshot_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1274663005 .
The system’s crashreporter_annotations_t structure was always present
as version 4 since Mac OS X 10.7. In OS X 10.11, it is now present as
version 5. It has also grown from 56 to 64 bytes per otool examination
of CoreFoundation’s __DATA,__crash_info section. The extra 8 bytes are
presumed to be a new field at the end of the structure, although this
is not confirmed.
The existing MachOImageAnnotationsReader.CrashAbort test only validated
that the “message” field in crashreporter_annotations_t was recovered
correctly, but
MachOImageAnnotationsReader::ReadCrashReporterClientAnnotations() also
recovers the “message2” field. A new test,
MachOImageAnnotationsReader.CrashModuleInitialization, is added to
ensure that the “messgae2” field can be recovered properly.
This change will resolve warnings such as:
[pid:tid:yyyymmdd,hhmmss.uuuuuu:WARNING
mach_o_image_annotations_reader.cc:82] unexpected crash info version 5
in
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
BUG=crashpad:40
TEST=crashpad_snapshot_test MachOImageAnnotationsReader.CrashAbort,
MachOImageAnnotationsReader.CrashModuleInitialization
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1277513003 .
OS X 10.11 introduces System Integrity Protection. One facet of that
forbids code injection into system executables. A Crashpad test checks
that information can be recovered from dyld in early-launch crashes by
requesting dyld load a nonexistent library with DYLD_INSERT_LIBRARIES.
The executable was meaningless but a system-provided executable,
/usr/bin/true, was used for convenience.
This test hung on OS X 10.11 because DYLD_INSERT_LIBRARIES was ignored
for the system executable, and no crash occurred. The test waited for a
crash that would never come.
A custom no-op executable, crashpad_snapshot_test_no_op, is provided as
an executable that does work with DYLD_INSERT_LIBRARIES.
BUG=crashpad:41
TEST=crashpad_snapshot_test MachOImageAnnotationsReader.CrashDyld
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1276553005 .
The cl_kernels bug (Apple bug 20239912) in which cl_kernels modules show
up with an __LD,__compact_unwind section inside the __TEXT segment, is
still present in Mac OS X 10.11. This results in these warnings and a
failure to load the module:
[pid:tid:yyyymmdd,hhmmss.uuuuuu:WARNING
mach_o_image_segment_reader.cc:142] section.segname incorrect in
segment __TEXT, section __LD,__compact_unwind 3/6, load command 0x19
0/6, module cl_kernels, address 0x10e964000
BUG=crashpad:42
TEST=crashpad_snapshot_test ProcessReader.*Modules
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1276573002 .
Both an SDK check and a runtime OS version check need to guard the use
of task_dyld_info_data_t::all_image_info_format. The SDK check, which
was already present, ensures that the field and macro constants are
present in the SDK. The runtime check is also necessary. This bug was
exposed in a 10.10 SDK and 10.6 deployment target build.
TEST=crashpad_snapshot_test ProcessTypes.DyldImagesSelf
BUG=chromium:463170
R=erikchen@chromium.org, rsesek@chromium.org
Review URL: https://codereview.chromium.org/1277523002 .
Now that we have a multiprocess test harness, add a test for
ProcessReaderWin for reading from a child.
Parent test code wasn't closing handles properly; fix that.
R=rsesek@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1160843006
This test was added in https://codereview.chromium.org/1052813002. It
was previously checking the timestamp from in-memory module traversal
vs. the disk mtime. This is flaky (of course) because it depends on
the linker writing the header and closing the file during the same time
quantum. So the bots occasionally failed with:
[ RUN ] ProcessInfo.Self
e:\b\build\slave\chromium_win_dbg\build\crashpad\util\win\process_info_test.cc(86): error: Value of: GetTimestampForModule(GetModuleHandleW(nullptr))
Actual: 1431650338
Expected: modules[0].timestamp
Which is: 1431650337
Instead, use imagehlp to pull the timestamp out of the header so that
it matches the header value that will be the in-memory timestamp.
R=cpu@chromium.orgTBR=mark@chromium.org
Review URL: https://codereview.chromium.org/1139103003
Retrieve context and save to thread context. NtQueryInformationThread
is no longer required (right now?) because to retrieve the CONTEXT, the
thread needs to be Suspend/ResumeThread'd anyway, and the return value
of SuspendThread is the previous SuspendCount.
I haven't handle the x86 case yet -- that would ideally be via
Wow64GetThreadContext (I think) but unfortunately that's Vista+, so I'll
likely need to to a bit of fiddling to get that sorted out. (It's actually
likely going to be NtQueryInformationThread again, but one thing at a
time for now.)
R=cpu@chromium.org, rsesek@chromium.orgTBR=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1133203002
The next big piece of functionality in snapshot. There's a bit more
grubbing around in the NT internals than would be nice, and it has
made me start to question the value avoiding MinidumpWriteDump. But
this seems to extract most of the data we need (I haven't pulled
the cpu context yet, but I hope that won't be too hard.)
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1131473005
- 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 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
The warnings are emitted when a translation unit attempts to reference
a function whose availability is newer than the deployment target.
BUG=471823
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1109273002
Patch from Erik Chen <erikchen@chromium.org>.
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
These two exception types use all 64 bits of the code[0] field. The
ExceptionSnapshot was unprepared to stuff this into a 32-bit field. To
resolve the discrepancy, the more-significant data is taken from the
high 32 bits of code[0]. No information is lost because the full code[0]
is made available as part of the Codes() vector.
BUG=crashpad:34
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1050313003
The wiki existed at https://code.google.com/p/crashpad/wiki, but given
Google Code Project Hosting’s impending shutdown[1], it’s prudent to
move wiki documents into the source code repository.
This change moves the existing contents of doc into doc/support, to make
way for documentation in doc. The two existing wiki pages, ProjectStatus
and DevelopingCrashpad, are converted to AsciiDoc format (a fairly
straightforward conversion) and checked in to doc. generate_asciidoc.sh
is updated to produce HTML output from these files. The generated HTML
will show up at http://docs.crashpad.googlecode.com/git/doc/. Note that
generated HTML is still hosted on Google Code Project Hosting, but it’ll
be easy to find a new home for them.
[1]
http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.htmlR=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1055523002
ExcServerCopyState() properly sets the new_state and new_state_count
out-parameters for exception handler routines that may deal with
state-carrying exceptions.
This used to exist inline in catch_exception_tool, but that
implementation had a bug caught by the new test.
TEST=crashpad_util_test ExcServerVariants.ExcServerCopyState and others
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1049023003
After 9e79ea1da719, it no longer makes sense for crashpad_util_test_lib
to “hide” in util/util_test.gyp. All of util/test is moved to its own
top-level directory, test, which all other test code is allowed to
depend on. test, too, is allowed to depend on all other non-test code.
In a future change, when crashpad_util_test_lib gains a dependency on
crashpad_client, it won’t look so weird for something in util (even
though it’s in util/test) to depend on something in client, because the
thing that needs to depend on client will live in test, not util.
BUG=crashpad:33
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1051533002
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
The test wasn’t strictly broken, but an <= written where a < was
intended caused some threads to log more messages than intended.
BUG=crashpad:26
TEST=crashpad_util_test ThreadLogMessages.Multithreaded
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1047813002
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
