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 .
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 .
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 .
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 .
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 .
In https://codereview.chromium.org/1411523006, the Mach port scopers are
becoming better ScopedGenerics and are losing the type conversion
operators in the process. This is needed to adapt to that change. get()
is ugly, but being explicit about conversion isn’t a bad thing, and
these scopers will gain functionality such as Pass() as part of the
switch.
As a bonus, some would-be uses of get() to check for valid port rights
are becoming a more descriptive is_valid().
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1405273002 .
This new test from 7de04b02f85d was failing on Windows 10. I started by
adding the hint, which produced “CreateFileMapping: Access is denied.
(0x5)â€. Switching the “Global\†to “Local\†fixes the test for me.
TEST=crashpad_util_test ProcessInfo.Handles
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1407993003 .
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 .
Capture the memory for the loader lock (can be inspected by !cs), as
well as all locks that were created with .DebugInfo which can be viewed
with !locks.
e.g.
0:000> !cs ntdll!LdrpLoaderLock
-----------------------------------------
Critical section = 0x778d6410 (ntdll!LdrpLoaderLock+0x0)
DebugInfo = 0x778d6b6c
NOT LOCKED
LockSemaphore = 0x0
SpinCount = 0x04000000
0:000> !locks -v
CritSec ntdll!RtlpProcessHeapsListLock+0 at 778d7620
LockCount NOT LOCKED
RecursionCount 0
OwningThread 0
EntryCount 0
ContentionCount 0
CritSec +7a0248 at 007a0248
LockCount NOT LOCKED
RecursionCount 0
OwningThread 0
EntryCount 0
ContentionCount 0
CritSec crashy_program!g_critical_section_with_debug_info+0 at 01342c48
LockCount NOT LOCKED
RecursionCount 0
OwningThread 0
EntryCount 0
ContentionCount 0
CritSec crashy_program!crashpad::`anonymous namespace'::g_test_critical_section+0 at 01342be0
WaiterWoken No
LockCount 0
RecursionCount 1
OwningThread 34b8
EntryCount 0
ContentionCount 0
*** Locked
Scanned 4 critical sections
R=mark@chromium.org
BUG=crashpad:52
Review URL: https://codereview.chromium.org/1392093003 .
This doesn’t really provide compatibility, it just ignores the
deprecation warning for +[NSURLConnection
sendSynchronousRequest:returningResponse:error:].
The suggested replacement, NSURLSession, was new in 10.9, and this code
needs to run on 10.6, so it’s not usable here, at least not without a
runtime check.
BUG=crashpad:65
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1395673002 .
We already use all the shared constants for page protection and type,
so rather than making various incompatible structures, just use
the MEMORY_BASIC_INFORMATION64 one directly, so that it can be directly
used.
R=mark@chromium.org
BUG=crashpad:20, crashpad:46
Review URL: https://codereview.chromium.org/1375313005 .
ExceptionPorts::GetExceptionPorts() returned a
std::vector<ExceptionPorts::ExceptionHandler>, which contained send
rights to Mach ports. The interface required callers to assume ownership
of each send right contained within the vector. This was cumbersome and
error-prone, and despite the care taken in Crashpad, port right leaks
did occur:
- SimulateCrash() didn’t make any attempt to release these resources at
all.
- Neither did crashpad_util_test ExceptionPorts.HostExceptionPorts,
which also reused a vector.
This replaces the vector with the interface-compatible (as far as
necessary) ExceptionPorts::ExceptionHandlerVector, which deallocates
collected port rights on destruction or clear().
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1381023007 .
This wraps bootstrap_check_in() in BootstrapCheckIn(), and
bootstrap_look_up() in BootstrapLookUp(). The wrappers make it more
difficult to accidentally leak a returned right. They’re easier to use,
encapsulating common error checking and logging, simplifying all call
sites.
TEST=crashpad_util_test MachExtensions.BootstrapCheckInAndLookUp
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1383283003 .
Chrome’s relauncher process needs a way to sever ties with the
crashpad_handler instance running from the disk image in order to cause
that instance to exit so that the disk image may be unmounted. This new
function is otherwise not thought to be interesting, and its use is not
recommended.
This comes with a small refactoring to create a
SystemCrashReporterHandler() function, and a fix for a minor port leak
in CrashReportExceptionHandler::CatchMachException().
BUG=chromium:538373
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1375573005 .
Sadly this code did not survive a collision with the real world. In
probing for the environment block there's a MEM_COMMIT region followed
directly by a MEM_RESERVE region (past the end of the environment
block).
Update region checker to correctly treat MEM_RESERVE as inaccessible.
R=mark@chromium.org
BUG=crashpad:20, crashpad:46, crashpad:59
Review URL: https://codereview.chromium.org/1370063005 .
On Win10, VirtualQueryEx supports querying the x64 part of WOW64
processes. However, on lower OSs it errors past 2/3G. There's no direct
way to retrieve to maximum memory address for processes other than
yourself, but fortunately, VirtualQueryEx sets a distinct error code
when `lpAddress` exceeds the maximum accessible address, so we can just
terminate successfully in that case.
R=mark@chromium.org
BUG=crashpad:20, crashpad:46
Review URL: https://codereview.chromium.org/1376353002 .
