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 .
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 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 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 .
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 .
Getting closer... Some tests passed on the last run, but the ones that
rely on having ntdll symbols fail on the bot. With `_NT_SYMBOL_PATH`
set, cdb will be able to download the PDBs so will be able to dump
data for `ntdll!_PEB`, etc.
R=mark@chromium.org
BUG=crashpad:46
Review URL: https://codereview.chromium.org/1402643002 .
Oops, was passing the out dir (...\crashpad\out), not the binary dir
(...\crashpad\out\Debug). Didn't notice because I was running the
script directly, rather than via run_tests.py. :/
R=mark@chromium.org
BUG=crashpad:46
Review URL: https://codereview.chromium.org/1394343005 .
I'd like to write some `expect(1)`-style tests (possibly using
http://pexpect.readthedocs.org/en/stable/) to verify that various windbg
commands that I'm adding support for do actually work when consuming
minidumps in real life.
For the moment, this is just the beginnings of a stub as I don't know if
bots even have windbg/cdb installed.
R=mark@chromium.org
BUG=crashpad:20, crashpad:46, crashpad:52
Review URL: https://codereview.chromium.org/1396943002 .
