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 .
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 .
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 .
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 .
After 9e79ea1da719, it no longer makes sense for crashpad_util_test_lib
to “hide” in util/util_test.gyp. All of util/test is moved to its own
top-level directory, test, which all other test code is allowed to
depend on. test, too, is allowed to depend on all other non-test code.
In a future change, when crashpad_util_test_lib gains a dependency on
crashpad_client, it won’t look so weird for something in util (even
though it’s in util/test) to depend on something in client, because the
thing that needs to depend on client will live in test, not util.
BUG=crashpad:33
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1051533002
In a future change, crashpad_util_test_lib will gain a dependency on
crashpad_client. This would violate GYP’s prohibition on circular
dependencies between .gyp files, although there would be no circular
relationship between the targets themselves. To overcome this problem,
all test-related targets are moved into their own first-class .gyp
files.
BUG=crashpad:33
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1045173004
Add MapInsertOrReplace<>() to insert a key-value pair into a map if the
key is not already present, or replace the existing value for key if the
key is present. The original value can optionally be returned to the
caller in this case.
Map insertions now use either MapInsertOrReplace<>() or
std::map<>::insert() directly.
Use MapInsertOrReplace<>() when the map should be updated to contain a
mapping from a key to a value regardless of whether the key is already
present.
Use std::map<>::insert() to insert a mapping from a key to a value
without replacing any existing mapping from a key, if present. If it is
important to know whether an existing mapping from a key was present,
use the returned std::pair<>.second. If it is important to know the
existing value, use the returned std::pair<>.first->second.
This change has a slight positive impact on performance.
TEST=crashpad_util_test MapInsert.MapInsertOrReplace and others
BUG=
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1044273002
Now that Chrome’s about:crashes displays the crash report UUID, I wanted
to add it to the minidump. In the future, we may be able to index these
on the server. This will also help identify dumps that correspond to the
same event once we’re equipped to convert between different formats.
Ideally, this new field is populated with the same UUID used locally in
the crash report database. To make this work,
CrashReportDatabase::NewReport must carry the UUID. This was actually
part of CrashReportDatabaseWin’s private extension to NewReport, so that
extension subclass can now be cleaned up.
TEST=crashpad_minidump_test MinidumpCrashpadInfoWriter.*,
crashpad_client_test CrashReportDatabaseTest.NewCrashReport
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1000263003
This regressed in 359bdd86225c when a non-POD UUID data member was added
to MinidumpCrashpadInfo, which made MinidumpCrashpadInfo non-POD. This
problem seems to have affected MinidumpModuleCodeViewRecordPDB70 since
it was added, but it is not likely to have caused any problems there
because that structure never appears without having all of its members
populated. By comparison, MinidumpCrashpadInfo may be sparsely
populated.
This caused 4 of the 5 MinidumpCrashpadInfoWriter tests to fail on
Windows.
TEST=crashpad_minidump_test MinidumpCrashpadInfoWriter.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1001683002
The client ID is added to a new field, MinidumpCrashpadInfo::client_id,
in each minidump file that is written. The ProcessSnapshot::ClientID()
gives access to value at the snapshot level. In the upload thread,
client IDs are retrieved from minidump files and used to populate the
“guid” HTTP form parameter.
The Breakpad client supplies these values at upload without hyphens and
with all capital letters. Currently, the Crashpad client uses hyphens
and lowercase letters when communicating with a Breakpad server.
TEST=crashpad_minidump_test MinidumpCrashpadInfoWriter.*,
crashpad_snapshot_test ProcessSnapshotMinidump.*,
run_with_crashpad --handler crashpad_handler \
-a --database=/tmp/crashpad_db \
-a --url=https://clients2.google.com/cr/staging_report \
-a --annotation=prod=crashpad \
-a --annotation=ver=0.7.0 \
crashy_program
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/998033002
Likewise for EXPECT_DEATH_CHECK() and EXPECT_DEATH().
In the in-Chromium build configured for official builds in Release mode,
CHECK() throws away its condition string and stream parameters without
ever printing them, although it still evaluates the condition and
triggers death appropriately. {ASSERT,EXPECT}_DEATH(statement, regex)
will not work correctly for any regex that attempts to match what
CHECK() prints. In these build configurations,
{ASSERT,EXPECT}_DEATH_CHECK() use a match-all regex (""). In other build
configurations, they transparently wrap {ASSERT,EXPECT}_DEATH().
BUG=crashpad:12
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/992693003
When building in the Chromium tree, this swaps out Crashpad’s copies of
mini_chromium, gtest, and gmock for the equivalents provided by
Chromium. A GYP variable, crashpad_in_chromium, is used to determine the
behavior.
gclient doesn’t sync sub-DEPS, so when doing an in-Chromium build,
Crashpad’s copies of mini_chromium, gtest, and gmock are not available.
BUG=crashpad:12
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/986033002
In Chromium, many targets are built, sharing a single output directory.
Collisions are likely. When integrating Crashpad into Chromium, the
ui/snapshot library and Crashpad’s snapshot library were found to
conflict.
This change gives most Crashpad targets a “crashpad_” prefix to avoid
conflicts. All library and test targets are given a target_name with
this prefix. Existing tools are not likely to conflict with anything
else and are not given a prefix.
BUG=crashpad:12
R=rsesek@chromium.org, scottmg@chromium.org
Review URL: https://codereview.chromium.org/990553003
When building in the Chromium tree, chromium_code is necessary to apply
Chromium’s build/filename_rules.gypi. Crashpad’s build depends on these
rules. chromium_code also enables a high warning level, which is
desirable for Crashpad.
BUG=crashpad:12
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/986873002
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
between classic and extension structures.
Previosly, each MinidumpModuleCrashpadInfo structure contained a
minidump_module_list_index field referencing a module in the
MINIDUMP_MODULE_LIST stream by index. This layout was discovered to
cause a problem for the new minidump reader in ModuleSnapshotMinidump.
Instead, the module list index for linkage should be contained in the
MinidumpModuleCrashpadInfoList alongside the LOCATION_DESCRIPTORs
pointing to each MinidumpModuleCrashpadInfo.
The organizational difference is small, but this enables a better design
for ModuleSnapshotMinidump. When initializing a ModuleSnapshotMinidump
with the new layout, it is possible for the caller to have access to the
location descriptor for the MinidumpModuleCrashpadInfo corresponding to
a MINIDUMP_MODULE_LIST. Previously, the caller would not have had this
data without interpreting each MinidumpModuleCrashpadInfo, which
ModuleSnapshotMinidump would have to do anyway.
MinidumpModuleCrashpadInfoListWriter was the only user of
MinidumpLocationDescriptorListWriter, which is obsoleted and removed in
this change. Its functionality is moving directly into
MinidumpModuleCrashpadInfoListWriter, but it is no longer generic enough
to maintain as a distinct class.
TEST=minidump_test \
MinidumpModuleCrashpadInfoWriter.*,MinidumpCrashpadInfoWriter.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/978463003
implement the new interface.
The upcoming minidump reader will get minidump data from a
FileReaderInterface. For ease of testing, a string-based implementation
is provided. There wasn’t a good reason to have a separate
StringFileReader and StringFileWriter, so I combined them into a single
StringFile.
TEST=util_test StringFile.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/936153002
Some annotations will exist at a broader scope than per-module, which is
the only place that annotations can currently be stored. The product
name and version are not under the control of any module, but are
established when the first Crashpad client establishes a handler. These
annotations will be stored in a minidump’s MinidumpCrashpadInfo
structure, which applies to the entire minidump.
Within the snapshot interface, this data is carried within the
“process” snapshot because it is the top-level structure in that family.
Note that the data may not correspond directly with a process, however.
TEST=minidump_test MinidumpCrashpadInfoWriter.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/924673003
The PUSH/POP are less noisy for sure. SUPPRESS is a little more
subtle -- it's correctly documented as "for this line and the next"
but that doesn't work well with our coding style.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/898133002
- Stack object instantiated for sizeof to avoid
d:\src\crashpad\crashpad\minidump\minidump_system_info_writer_test.cc(43) : error C2597: illegal reference to non-static member '_MINIDUMP_STRING::Buffer'
Could also just be sizeof(WCHAR) if that feels less ugly.
- narrowing cast
- potentially uninitialize variable warning
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/886143004
MINIDUMP_MISC_INFO and MINIDUMP_MISC_INFO_2, etc. are not
derived from each other in Windows' dbghelp.h, so need
a reinterpret_cast.
arraysize fails on Struct::Member with a big mess (below)
but works ok on a local stack instance.
d:\src\crashpad\crashpad\minidump\minidump_misc_info_writer_test.cc(405) : error C2664: 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>::basic_string(std::initializer_list<_Elem>,const std::allocator<char> &)' : cannot convert argument 1 from 'char' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &'
with
[
_Elem=char
]
Reason: cannot convert from 'char' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>>'
No constructor could take the source type, or constructor overload resolution was ambiguous
d:\src\crashpad\crashpad\minidump\minidump_misc_info_writer_test.cc(408) : error C2784: 'char (&ArraySizeHelper(const T (&)[N]))[N]' : could not deduce template argument for 'const T (&)[N]' from 'unknown'
d:\src\crashpad\crashpad\third_party\mini_chromium\mini_chromium\base\basictypes.h(39) : see declaration of 'ArraySizeHelper'
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/899163004
test_process_snapshot.h apparently requires the full inclusion,
not a forward declaration otherwise it claims to be deleting
undefined types.
And, some more potentially uninitialized variables.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/902803002
Had to move this one out to a scoped_ptr too, otherwise when
it's instantiated in test code on the stack,
d:\src\crashpad\crashpad\minidump\minidump_simple_string_dictionary_writer_test.cc(45) : warning C4815: 'dictionary_writer' : zero-sized array in stack object will have no elements (unless the object is an aggregate that has been aggregate initialized)
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/895313004
A (somewhat cursory) inspection leads me to believe that there's
no particular alignment requirements for this object at this location,
so this warning can be ignored.
d:\src\crashpad\crashpad\minidump\minidump_context_writer.cc(43) : error C2220: warning treated as error - no 'object' file generated
d:\src\crashpad\crashpad\minidump\minidump_context_writer.cc(43) : warning C4316: 'crashpad::MinidumpContextAMD64Writer' : object allocated on the heap may not be aligned 16
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/893393002
- dbghelp.h requires windows.h to be included before it (ick!).
Add a stub one for non_win to make this work.
- convert __attribute__ -> macro that can work work with MSVC;
- a handful of narrowing casts.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/883773005
MinidumpLocationDescriptorListWriter and MinidumpRVAListWriter are
implementation details and should be in the crashpad::internal
namespace.
MinidumpUTF16StringListWriter and MinidumpUTF8StringListWriter are
accessible to outside code and should not be in this namespace.
TEST=minidump_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/699313007
This will be used as the foundation for writing a list of
MinidumpUTF8String objects. MinidumpUTF8String (and UTF-16
MINIDUMP_STRING) objects are never referenced by
MINIDUMP_LOCATION_DESCRIPTOR because they carry their own lengths.
Instead, they are always referenced by RVA.
The list of MinidumpUTF8String objects will be used for the module
annotations vector.
TEST=minidump_test MinidumpRVAListWriter.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/704333002
MinidumpLocationDescriptorListWriter. This allows easier construction of
minidump structures that are lists of MINIDUMP_LOCATION_DESCRIPTOR
structures in the future.
TEST=minidump_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/707543002
MinidumpWritableAtRVA<>() now checks that the object of the requested
type is actually in the range of the minidump file’s size, rather than
just checking that the beginning of the object is in range.
TEST=minidump_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/708803002
implicit_cast<> only performs a cast in cases where an implicit
conversion would be possible. It’s even safer than static_cast<> It’s an
“explicit implicit” cast, which is not normally necsesary, but is
frequently required when working with the ?: operator, functions like
std::min() and std::max(), and logging and testing macros.
The public style guide does not mention implicit_cast<> only because it
is not part of the standard library, but would otherwise require it in
these situations. Since base does provide implicit_cast<>, it should be
used whenever possible.
The only uses of static_cast<> not converted to implicit_cast<> are
those that require static_cast<>, such as those that assign an integer
constant to a variable of an enum type.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/700383007
and its test.
Minidump context structures now interoperate more easily with snapshot
CPUContext structures, while maintaining identical layout to before.
This is facilitated by reusing the Fxsave types for the substructures
which were completely identical, and by using compatible logic to
initialize the minidump and snapshot structures for testing.
TEST=minidump_test, snapshot_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/686353004
All minidump objects now own their all of their children, rather than
having them maintain weak pointers and requiring callers to maintain
ownership.
The only weak object in the entire tree now is the “extra memory” added
to a MinidumpMemoryListWriter by its AddExtraMemory() method. Extra
memory aliases objects owned elsewhere in the tree, typically by a
MinidumpThreadWriter as stack memory. Non-“extra” memory added to a
MinidumpMemoryListWriter by its AddMemory() method is strongly owned.
Many objects are now deleted through base pointers, and in those cases,
the base classes now have public virtual destructors. The ultimate base,
MinidumpWritable, is still protected to guard against direct
instantiation and deletion, and thus its destructor does not need to be
virtual.
This updates mini_chromium to eeb3b6a4f020 specifically for that
revision, which includes necessary updates to scoped_ptr. It also picks
up:
eeb3b6a4f020 Update base/move.h and base/memory/scoped_ptr.h to match
67ad2efafaba More porting to Windows
be27a006421e AUTHORS: Fix link post-git migration flag day.
05f5b1503230 Add codereview.settings to mini_chromium.
a32c2b199811 Beginnings of Windows support in mini_chromium
TEST=minidump_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/674153002
test.
Move SimpleAnnotations from being a property of the minidump to being a
property of the module, matching the Snapshot interface.
TEST=minidump_test MinidumpCrashpadInfo.*:MinidumpCrashpadModule.*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/675803002
This change was generated mechanically by running:
find . \( -name \*.cc -or -name \*.mm -or -name \*.h \) \
-and -not -path ./third_party/\* -and -not -path ./out/\* \
-exec sed -i '' -E -e 's/(^|[^_])NULL/\1nullptr/g' {} +
Further manual fix-ups were applied to remove casts of nullptr to other
pointer types where possible, to preserve the intentional use of NULL
(as a short form of MACH_PORT_NULL) in exception_port_tool, and to fix
80-column violations.
https://groups.google.com/a/chromium.org/d/topic/chromium-dev/4mijeJHzxLg/discussion
TEST=*_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/656703002
This is in line with the other new minidump_*_test_util files, namely,
the “context” and “memory” ones. minidump_file_writer_test_util.*
provides VerifyMinidumpHeader(), which is used to validate the
MINIDUMP_HEADER at the beginning of a minidump file, as written by
MinidumpFileWriter.
TEST=minidump_test
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/643643003
This fixes a sloppy compliation error: “Redefinition of enumerator
'kMinidumpContextX86Xstate'”. It also fixes CONTEXT_FULL, which should
contain floating-point registers but not segment registers unlike the
its 32-bit x86 equivalent.
Some comments are revised to provide better, um, context.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/620663002
time_t is a typedef for long on Mac OS X. In 32-bit x86 (ILP32), long is
a signed 32-bit quantity, and its range does not contain the range of
uint32_t, used to store times in time_t fashion in minidump files. A
cast is necessary to make these EXPECT_* macros do the right thing. This
is not a problem in x86_64 (LP64) where long is a signed 64-bit
quantity, which does contain the range of uint32_t.
clang’s error was “error: comparison of integers of different signs:
'const long' and 'const unsigned int' [-Werror,-Wsign-compare]”
BUG=
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/491023005
MinidumpFileWriter writes the top-level object to a minidump file. This
consists of a MINIDUMP_HEADER and a list of MINIDUMP_DIRECTORY entries
that point to streams, which are second-level objects in minidump files.
This change also adds the base class for stream writers,
MinidumpStreamWriter.
TEST=minidump_test MinidumpFileWriter*
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/432863006
