sed -i '' -E -e 's/Copyright (.+) The Crashpad Authors\. All rights reserved\.$/Copyright \1 The Crashpad Authors/' $(git grep -El 'Copyright (.+) The Crashpad Authors\. All rights reserved\.$')
Bug: chromium:1098010
Change-Id: I8d6138469ddbe3d281a5d83f64cf918ec2491611
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3878262
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This change was partially scripted and partially done manually with vim
regex + manually placing the deleted constructors.
The script change looked for destructors in the public: section of a
class, if that existed the deleted constructors would go before the
destructor.
For manual placement I looked for any constructor in the public: section
of the corresponding class. If there wasn't one, then it would ideally
have gone as the first entry except below enums, classes and typedefs.
This may not have been perfect, but is hopefully good enough. Fingers
crossed.
#include "base/macros.h" is removed from files that don't use
ignore_result, which is the only other thing defined in base/macros.h.
Bug: chromium:1010217
Change-Id: I099526255a40b1ac1264904b4ece2f3f503c9418
Reviewed-on: https://chromium-review.googlesource.com/c/crashpad/crashpad/+/3171034
Reviewed-by: Mark Mentovai <mark@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Change-Id: I4b247d7fae1a212350f8ffcf2bf5ba1fa730f5c1
Reviewed-on: https://chromium-review.googlesource.com/780339
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
BUG=crashpad:158
Change-Id: If8666140a7fc5315eeb791d0998226de89a22cc3
Reviewed-on: https://chromium-review.googlesource.com/438791
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
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 .
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 .
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 .
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 .
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 .
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 .
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 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
This only works 64->64, 32->32, and 64->32. We shouldn't have a
need for 32->64. It will also currently not work if the crash service
is running on Wow64 itself (that is, 32->32, but on an x64 OS). We
should also be able to avoid needing that.
Primarily, this change templatizes the winternl.h process structure
types on word size, so the PEB can be read in a foreign bitsize process.
This also happens to resolve using void* as pointer values into foreign
processes, as they're now all either DWORD or DWORD64 depending on which
traits class is used.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/981393003
Mostly size_t <-> unsigned int warnings, but I also had a mistake in
PROCESS_BASIC_INFORMATION, the pids are 32-on-32 and 64-on-64.
The Windows build is still x86 until https://codereview.chromium.org/981333002/.
I don't think I'll bother maintaining the x86 build for now, though we will probably
need it for x86 OSs in the future. It should be straightforward to revive it once we
need it, and have bots to support it.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/983103004
This is as a precursor to ProcessReader. Some basic functionality
is included for now, with more to be added later as necessary.
The PEB code is pretty icky -- walking the doubly-linked list
in the target's address space is cumbersome. The alternative
is to use EnumProcessModules. That would work but:
1) needs different APIs for XP and Vista 64+
2) retrieves modules in memory-location order, rather than
initialization order. I felt retrieving them in initialization order
might be useful when detecting third party DLL injections. In the
end, we may want to make both orders available.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/977003003