Kasko needs a way to read crash keys from out of process. This API
reuses the functionality of PEImageAnnotationsReader.
Change-Id: I2f3bbc358212e6f50235183e9dbb4e5a2cf989cf
This is a reupload of https://codereview.chromium.org/1586433003/ but
for gerrit.
Change-Id: I2f3bbc358212e6f50235183e9dbb4e5a2cf989cf
Reviewed-on: https://chromium-review.googlesource.com/322550
Reviewed-by: Scott Graham <scottmg@chromium.org>
Tested-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@google.com>
It has no effect on Gerrit hosts. The notification settings within
Gerrit need to be configured.
Change-Id: I6ab9ed0d6f55742ebe934924cc9272efd7e2f3c6
BUG=
Change-Id: I592e0dcacfc41d90bf7c0e6800cd8e2c411c6c2c
Reviewed-on: https://chromium-review.googlesource.com/322190
Tested-by: Andrew Bonventre <andybons@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
The previous approach was nice for its simplicity, but unfortunately
didn't work when the compiler decided to do some of its confounded
"optimization".
R=mark@chromium.org
BUG=crashpad:86, chromium:571144
Review URL: https://codereview.chromium.org/1563273004 .
This is a temporary measure to try to account for lower than expected
upload volume from Chrome in the wild. So this doesn't fix bug 23, but
is related. The ability to delimit the upload rate is useful when
testing locally too.
R=mark@chromium.org
BUG=crashpad:23
Review URL: https://codereview.chromium.org/1563683002 .
a43fee120b10 Sync Mac scopers with upstream Chromium
This adapts to updated Mac scopers from Chromium cfd6ed5600d8, including
the changes from that commit and Chromium f39d4ffc6c32.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1565873002 .
This was done in Chromium’s local copy of Crashpad in 562827afb599. This
change is similar to that one, except more care was taken to avoid
including headers from a .cc or _test.cc when already included by the
associated .h. Rather than using <stddef.h> for size_t, Crashpad has
always used <sys/types.h>, so that’s used here as well.
This updates mini_chromium to 8a2363f486e3a0dc562a68884832d06d28d38dcc,
which removes base/basictypes.h.
e128dcf10122 Remove base/move.h; use std::move() instead of Pass()
8a2363f486e3 Move basictypes.h to macros.h
R=avi@chromium.org
Review URL: https://codereview.chromium.org/1566713002 .
../../handler/crash_report_upload_thread.cc:142:7: error: field 'database_' will be initialized after field 'thread_' [-Werror,-Wreorder]
database_(database),
^
1 error generated.
And:
..\util\thread\worker_thread_test.cc(25) : warning C4244: 'initializing' : conversion from 'double' to 'const uint64_t', possible loss of data
BUG=crashpad:22
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1556043005 .
Fix some warnings when compiling crashpad with VC++ 2015 Update 1.
Warning 4302 occurs if you convert from a pointer to a <sizeof(void*)
integer in one cast, because this often indicates an accidental pointer
truncation which can be a bug in 64-bit builds.
Warning 4577 warns that noexcept will not be enforced, but we don't want
it to be enforced anyway, so I disabled it. The full warning is:
warning C4577: 'noexcept' used with no exception handling mode specified
termination on exception is not guaranteed. Specify /EHsc
BUG=440500
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1527803002 .
Patch from Bruce Dawson <brucedawson@chromium.org>.
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 .
The BaseName() was added because system DLLs were being reported by
GetFileVersionInfo()/VerQueryValue() as having major file versions of
6.2 instead of 10.0 on Windows 10 when accessed by full path, but not
by BaseName(). The PEImageReader gets the correct version from the
in-memory images, 10.0.
This trick didn't work on Windows XP, where two copies of comctl32.dll
were found loaded into the process, one with a major file version of
5.82 and the other with 6.0. Giving GetFileVersionInfo() the BaseName()
would result in it returning information from one of these, which would
cause the version to not match when the PEImageReader was looking at the
other.
All of these GetFileVersionInfo() quirks make me glad that we're not
using it anymore (outside of the test).
Because of the version numbers involved (NT 6.2 = Windows 8, where
GetVersion()/GetVersionEx() start behaving differently for
non-manifested applications) and the fact that GetFileVersionInfo()
and VerQueryValue() seem to report 10.0 even with full paths on Windows
10 in applications manifested to run on that OS, the BaseName() thing is
restricted to Windows 8 and higher.
TEST=crashpad_snapshot_test PEImageReader.VSFixedFileInfo_AllModules
BUG=crashpad:78
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1493933002 .
Don't call GetFileVersionInfo(), which calls LoadLibrary() to be able to
access the module's resources. Loading modules from the crashy process
into the handler process can cause trouble. The Crashpad handler
definitely doesn't want to run arbitrary modules' module initializer
code.
Since the VS_FIXEDFILEINFO needed is already in memory in the remote
process' address space, just access it from there.
BUG=crashpad:78
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1475023004 .
On Win 7 in a debug configuration, walking all locks was gathering
hundreds of thousands of locks, causing test timeouts to be exceeded in
debug. On user machines, UnhandledExceptionHandler() could have timed
out too. For now, only grab the loader lock as it's the most interesting
one. Unfortunately, this means that !locks won't work for now.
In the future, we may want to figure out a signalling mechanism so that
the client can note other interesting locks to be grabbed, and just
avoid walking the list entirely.
R=mark@chromium.org
BUG=chromium:546288
Review URL: https://codereview.chromium.org/1475033005 .
This reverts commit b3464d96f5fc0d82f860651b7918626dfbd80d65.
It was temporarily landed to be able to run as the DEPS version in Chrome.
BUG=
Review URL: https://codereview.chromium.org/1474223002 .
On Win 7 in a debug configuration, this was gathering hundreds of
thousands of locks, causing test timeouts to be exceeded. On user
machines, UnhandledExceptionHandler() probably would have timed out
also. Arbitrarily cap the number of locks captured, as we don't have a
pressing need for anything other than the LoaderLock anyway.
In the future, we may want to figure out a signalling mechanism so that
the client can note other interesting locks to be grabbed, and just
avoid walking the list entirely.
R=mark@chromium.org
BUG=chromium:546288
Review URL: https://codereview.chromium.org/1475033005 .
FILE_TYPE_CHAR handles can't be inherited via
PROC_THREAD_ATTRIBUTE_HANDLE_LIST, or CreateProcess() fails with
GetLastError() == 1450 on Windows 7.
I confirmed that an fprintf(stderr, ...) in HandlerMain() does make it
to the console when running tests even after this.
See bug for more discussion.
R=mark@chromium.org
BUG=crashpad:77
Review URL: https://codereview.chromium.org/1473793002 .
This log spam from end_to_end_test.py indicated that
GetFileVersionInfo() was being called three times per module:
[3076:3424:20151123,102817.290:WARNING module_version.cc:29]
GetFileVersionInfoSize: ...\crashpad\out\Release_x64\crashy_program.exe:
The specified resource type cannot be found in the image file. (1813)
[3076:3424:20151123,102817.291:WARNING module_version.cc:29]
GetFileVersionInfoSize: ...\crashpad\out\Release_x64\crashy_program.exe:
The specified resource type cannot be found in the image file. (1813)
[3076:3424:20151123,102817.291:WARNING module_version.cc:29]
GetFileVersionInfoSize: ...\crashpad\out\Release_x64\crashy_program.exe:
The specified resource type cannot be found in the image file. (1813)
This is unnecessary. It only needs to be called once.
We may want to avoid logging in GetModuleVersionAndType() when
GetLastError() is ERROR_RESOURCE_TYPE_NOT_FOUND.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1472963002 .
8b085f0d2168 Fix warnings encountered in MSVC build of gtest/gmock tests
322a4914a309 Better use of character constants
cbce23fb8670 Leave decltype(max_ulps_) alone and cast, not sure this is
better
cfe466a0a753 Use a templated helper to wrap the cast
4a8e54401e49 Name the helper AsBits()
786564fa4a3c Merge pull request #627 from mark-chromium/tests_msvs
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1467283002 .
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 .
985372e5da14 win: Send log messages to a debugger via
OutputDebugString()
06e0fa1309a0 win: Use FormatMessage[W]() instead of FormatMessageA() for
logging
ea8d8de53f94 mac: Log messages to the system log via ASL
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1417803006 .
The bug and linked code review has more of the history, but we’ve been
tempted to remove the loop outright a couple of times already before
realizing that it serves an important purpose. Hopefully this comment
will protect our future selves from going on the same fool’s errand.
BUG=crashpad:75
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1427643010 .
Previously, there was a window after starting the upload thread but
before the SIGTERM handler was installed, where receipt of SIGTERM
could have interrupted an in-progress upload. There was also the
possibility that a second SIGTERM sent after the exception handler
stopped running would interrupt an in-progress upload. By pulling the
signal handler out of ExceptionHandlerServer and into the main
function, these races are avoided.
BUG=crashpad:25
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1429353002 .
This is better because now end_to_end_test.py fails immediately with
[1180:9020:20151106,145204.830:ERROR registration_protocol_win.cc:39] CreateFile: The system cannot find the file specified. (0x2)
R=mark@chromium.org
BUG=crashpad:75
Review URL: https://codereview.chromium.org/1409693011 .
This requires Windows NT 6.0 (Vista and Server 2008). On earlier
operating system versions, the existing behavior of inheriting all
inheritable handles is retained.
BUG=crashpad:69
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1427273003 .
I've heard/lived enough horror stories about AV, outbound-blocking
firewalls, etc. on Windows, that I think the best approach is to have
chrome.exe embed the majority of crashpad_handler and jump to it as
early as possible when running in that mode.
So, move most of crashpad_handler into a static_library with just main()
in the executable target.
R=mark@chromium.org
BUG=chromium:546288, crashpad:27
Review URL: https://codereview.chromium.org/1416873016 .
In 2eeaa3ac549a, I added a check to make sure that the expected CONOUT$
handle was found. Its omission seemed to be unintentional. The tests
passed for me on Windows 10, but failed on the bots. I can reproduce
the failures locally on Windows 7.
Doing the inheritance test with a file other than CONOUT$ fixes the
immediate problem, but we should find out why this CONOUT$ handle isn't
showing up in the handles list on Windows 7, fix it, and add back a
test.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1428753009 .
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 .
Allowing the client to create its own pipe name string caused a race
between client and server. Instead, in this mode, the server now creates
the pipe name along with a pipe, and returns it to its client via a
--handshake-handle. This guarantees that by the time the client gets the
pipe name, the server has already created it.
Ephemeral mode is now implied by --handshake-handle. The --persistent
option is gone. --persistent mode is enabled when using --pipe-name.
BUG=crashpad:69
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1432563003 .
By invoking crashpad_handler with --mach-service instead of
--handshake-fd, the handler will run as a well-behaved launchd job. The
launchd job may be as a launch agent or launch daemon, or be submitted
to launchd by on_demand_service_tool.
BUG=crashpad:25
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1414533006 .
For multiprocess architectures, this method allows the pipe used for
registration to be obtained from CrashpadHandler, even when
CrashpadHandler chooses its own name. This may happen if the handler is
not running on a well-known pipe name but was instead started by
CrashpadHandler::StartHandler(). If Chrome uses this interface, for
example, the browser process will need to call
CrashpadClient::GetHandlerIPCPipe() and pass the pipe name to its child
processes.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1427163004 .
This is necessary for 64 bit tools installed on a 64 bit OS, but with
the tests run from a 32 bit Python. (sigh)
Doesn't happen on bots, but comes up occasionally testing on VMs.
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1425153003 .
I considered writing the CodeView records to the minidump, but I didn't
find a ton of docs and debugging is only lightly supported (e.g.
http://www.debuginfo.com/articles/gendebuginfo.html#debuggersandformats
and it doesn't attempt to load at all on more recent Visual Studios).
As we won't be generating symbols in this format, and we don't expect to
have symbols for any weird modules that get injected into us in the
wild, it seems like we don't lose anything by just ignoring them.
R=mark@chromium.org
BUG=crashpad:47
Review URL: https://codereview.chromium.org/1430773003 .
Each routine in this implementation returns MIG_BAD_ID. These routines
may be overridden.
Most things that implement NotifyServer::Interface will only need to
implement one of the interface routines. Since another user of
NotifyServer will be added soon, it makes sense to provide a default
no-op implementation rather than forcing everyone to write the same
no-op boilerplate repeatedly.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1414413006 .
Previously, crashpad_handler made its own receive right, and transferred
a corresponding send right to its client. There are two advantages to
making the receive right in the client:
- It is possible to monitor the receive right for a port-destroyed
notificaiton in the client, allowing the handler to be restarted if
it dies.
- For the future run-from-launchd mode (bug crashpad:25), the handler
will obtain its receive right from the bootstrap server instead of
making its own. Having the handler get its receive right from
different sources allows more code to be shared than if it were to
sometimes get a receive right and sometimes make a receive right and
transfer a send right.
This includes a restructuring in crashpad_client_mac.cc that will make
it easier to give it an option to restart crashpad_handler if it dies.
The handler starting logic should all behave the same as before.
BUG=crashpad:68
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1409073013 .
This allows better code sharing in crashpad_handler’s main(). It doesn’t
look like much of an improvement now, but a separate change will cause
the Mac ExceptionHandlerServer() to be constructed with an argument. It
will be beneficial for Mac and Windows to be able to share the Run()
call.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1402333004 .
The intended use is to flip the client-server relationship in
CrashpadClient so that the initial client (parent process) furnishes the
handler process with a receive right. The parent can optionally receive
a port-destroyed notification allowing it to restart the handler if it
exits prematurely.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1408473002 .
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 .
