This makes the basics of !peb work in windbg, however, pointed-to things
are not yet retrieved. For full functionality, a variety of pointers in
the PEB also needs to be walked and captured.
e.g.
Previously:
0:000> .ecxr
eax=00000007 ebx=7e383000 ecx=c3f9a943 edx=00000000 esi=006d62d0 edi=003c9280
eip=00384828 esp=005bf634 ebp=005bf638 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28:
00384828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=????????
0:000> !peb
PEB at 7e383000
error 1 InitTypeRead( nt!_PEB at 7e383000)...
Now:
0:000> .ecxr
eax=00000007 ebx=7f958000 ecx=02102f4d edx=00000000 esi=00e162d0 edi=01389280
eip=01344828 esp=00c2fb64 ebp=00c2fb68 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
crashy_program!crashpad::`anonymous namespace'::SomeCrashyFunction+0x28:
01344828 c7002a000000 mov dword ptr [eax],2Ah ds:002b:00000007=????????
0:000> !peb
PEB at 7f958000
InheritedAddressSpace: No
ReadImageFileExecOptions: No
BeingDebugged: No
ImageBaseAddress: 01340000
Ldr 77ec8b40
*** unable to read Ldr table at 77ec8b40
SubSystemData: 00000000
ProcessHeap: 00e10000
ProcessParameters: 00e114e0
CurrentDirectory: '< Name not readable >'
WindowTitle: '< Name not readable >'
ImageFile: '< Name not readable >'
CommandLine: '< Name not readable >'
DllPath: '< Name not readable >'
Environment: 00000000
Unable to read Environment string.
R=mark@chromium.org
BUG=crashpad:46
Review URL: https://codereview.chromium.org/1364053002 .
Ninja assumes all DLLs will have an import library generated (caused
when there are any exports), but because this DLL is so simple, it does
not. This makes ninja think that the target is always dirty and so it
rebuilds it on every build. Fix this by telling ninja not to expect an
import library.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1346253003 .
Removes the bitness-specific targets in favour of pulling binaries from
the other build directory. This is to avoid the added complexity of
duplicating all the targets for the x86 in x64 build.
Overall, mostly templatizing more functions to support the
wow64-flavoured structures. The only additional functionality required
is reading the x86 TEB that's chained from the x64 TEB when running
as WOW64.
The crashing child test was switched to a manual CreateProcess because
it needs to launch a binary other than itself.
R=mark@chromium.org
BUG=crashpad:50
Review URL: https://codereview.chromium.org/1349313003 .
8c31354f5e0c Fix mixed line endings warning
4f4c7cb5a63e Add TestGypXcodeNinja to run tests against the xcode-ninja
generator
f1dc682b70a6 Fix: xcode-ninja should generate Xcode workspace into
generator_output
cdf037c1edc0 Fix: xcode-ninja should copy the product extension to the
wrapper project
82b08049cc0b Set ZERO_AR_DATE=1 when running libtool.
8b69f7d23df5 Add support for generating an Eclipse .classpath file (bug
fix)
789a019a8320 Don't serialize linking for the make generator by default
194ec65a55ed Revert 2011 'Fixed Gyp Xcode generator for libraries with
identical names.'
91a89564da3d Add 'depfile' option to actions.
3dde7bfb50a6 don't assume bash is installed
28384e55a5c8 msvs/ninja win: Fix support for
ImageHasSafeExceptionHandlers
adb7d24b9fc1 Revert "msvs/ninja win: Fix support for
ImageHasSafeExceptionHandlers"
b28bd7ddd143 win: 'EnableEnhancedInstructionSet': '5' now enables
/arch:AVX2.
104e21ecf6f2 mac: Followup to ZERO_AR_DATE, touch the -o archive,
rather than expecting only one
4d7c139b1820 win: Add NoImportLibrary flag for ninja generator
67000714d51e Reland "msvs/ninja win: Fix support for
ImageHasSafeExceptionHandlers"
16f9f4566f5d msvs: Prefer x64 toolset if we are running on 64-bit
6194e32f7fcb Make msvs-ninja work for target-arch=x64
34640080d08a ninja/posix: Introduce support for arflags variable.
7cd601835636 Updating gyp repo for git, preparing for cq.
dd831fd86e7a Fix script url.
a5bd08f28629 Adds the ability for 'copies' in Xcode project files to
specify the 'Code Sign on Copy' option.
002ebe4420a3 Fixed version of https://codereview.chromium.org/748793002
50ab31edc847 Fix typo in ternary operator.
4a9b712d5cb4 Fix gyp analyzer generator on mac.
d9823985797f Convert plist and strings to binary for iOS.
28c00336a403 Bump Xcode compatibility version from 45 (Xcode 2.4-3.1) to
46 (Xcode 3.2).
2cd9d0633c96 [ninja-xcode] Include action inputs in hybrid builds.
d174d75bf69c Export generator flavor to gyp scripts
2b44e5987d5a Add missing identity variables to gypd generator.
e1c8fcf74b68 Assert when source is an absolute path
c5859a298166 Migrate GYP docs over from the wiki.
69dfb493a22f LLVM_LTO support for make / ninja
2889664b9fa8 Address scottmg comments from
https://codereview.chromium.org/1003273007/.
2a5511bd901f Improve generated Makefile rules for rules several outputs.
2f66a3f94953 Whitespace change to test the new GYP waterfalls.
3601f26003c6 Make dump_dependency_json.py write <| list files to the
output directory rather than the source tree.
8866260996c0 win: prefer amd64_x86 compiler on >= 2013, not just 2013
0bb67471bca0 Slightly better docs for git instead of svn
f34b9aa7c9d6 Remove the Android generator.
9f594095c5b1 Added msvs_application_type_revision for winrt compilation
c0cf1f22eb42 Revert "Stop checking for duplicate basenames"
4dd5d3c614fb Update shared_library test after c0cf1f22eb
29e94a3285ee Avoid lint presubmit error in dump_dependency_json
08429da7955a Update cmake generator to handle Skia Android build.
aa537916dcb5 msvs: Make sure stdout/stderr from rule commands get logged
fdc7b812f99e Makes analyzer always output static_libraries that have
changed
79de4031069f Fix gyp->make translation of rules with several outputs.
9b2b25aececd Correct braces in input format reference doc.
b4781fc38236 MSVS: Normalize paths against gyp directory.
127b311bf61d Adds some debugging output to analyzer
fdcd8bc10c93 More debugging for analyzer
acfc10d29072 Revert "MSVS: Normalize paths against gyp directory."
5122240c5e5c Fix support for iOS today extensions on latest Xcode beta.
ae276266d580 Make DependencyGraph.DeepDependencies() depth-first.
25ed9ac4ac2a Do not remote duplicate entries from ldflags when
generating ninja files as it changes behavior
6ee91ad86598 Reduce DefaultConcurrentLinks from phys/4GB to phys/5GB.
658f3a81995b Disable currently failing gyp tests on win to make the bots
green.
479dacf7be5f Disable GYP tests currently failing on the Mac bot
36d99ff23099 Disable test/win/gyptest-link-defrelink.py
d6adc48df899 Fix the default tryserver lists in PRESUBMIT.py.
81c2e5ff92af Added msvs_target_platform_version and
msvs_target_platform_minversion for winrt compilation
010fb9d696e7 msvs_emulation: Add support for StackReserveSize and
StackCommitSize
edccc7bad7da Analyzer didn't match correctly targets that defined path
to inputs with '.' relative path values. So let normalize
path before matching.
bae26e800c7f Inject pylib first in the path. This ensures that test load
the version of pylib in this repo, not elsewhere on the
system.
008cf1c04393 Improve error messages when <!(commands) fail
121d89dfcd4f Make RelativePath use abspath rather than realpath for the
'path' variable. This allows gyp to work correctly in
symlink-heavy environments. Basically, this is because gyp
paths need to be in a consistent tree, so we need to
compute a path to the target within the *stated* tree, even
if it is not the real underlying path to the target. The
'relative_path' variable does need to be resolved using
realpath, since gyp or the underlying build system might cd
to it before looking for the 'path' target.
2b17e0b26a93 Fix paths with different seperators being compared in the
analyzer on Windows.
5d01a8cda53b Revert "Make RelativePath use abspath rather than realpath
for the 'path' variable."
1f374df95de1 Make sure GYP supports compiling managed code.
cf3170e30578 Update gyp LINK_COMMANDS_AIX to support both 32-bit and
64-bit files. * cmd_alink: Add -X32_64 option. *
cmd_alink_thin: Add -X32_64 option.
01528c724483 Fallback to '.tbd' for system missing '.dylib'.
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1358583003 .
A few function implementations that were missing, various switches
for functions/functionality that didn't exist on XP, and far too long
figuring out what exactly was wrong with SYSTEM_PROCESS_INFORMATION
on x86 (the "alignment_for_x86" fields).
R=mark@chromium.org
BUG=crashpad:1, crashpad:50, chromium:531663
Review URL: https://codereview.chromium.org/1336823002 .
The pipe handle was being leaked on connections (oops!). On XP this
resulted in the next test's CreateNamedPipe to fail, because the
previous one still existed (because all handles were not closed). More
recent OSs are more forgiving so I got away with the buggy code.
R=mark@chromium.org
BUG=crashpad:50
Review URL: https://codereview.chromium.org/1337953003 .
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 .
