One possible cause for this would be a register "pointing" to the edge of an
inaccessible range. Having these zero-sized ranges doesn't break the minidump,
but it causes a warning when opening in windbg.
Also drop user-supplied zero-length memory ranges for the same reason.
BUG=crashpad:104
Change-Id: I2c5acc54f04fb617806cecd87ac4ad5db93f3db8
Reviewed-on: https://chromium-review.googlesource.com/339210
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
In debug builds, the extra memory is sometimes getting captured
(probably by a stale stack pointer), so disable this test for now to
un-red the bots. We can probably fix it by moving this one test to a
separate binary (or perhaps just removing it, I'm not sure it's that
useful anyway above and beyond the unit test.)
R=mark@chromium.org
BUG=crashpad:101
Change-Id: I98a58a467fb4a4d9f84d2e0d020a031a0ea9743c
Reviewed-on: https://chromium-review.googlesource.com/334821
Reviewed-by: Scott Graham <scottmg@chromium.org>
Forgot some u number suffixes.
BUG=crashpad:94
Change-Id: I2a3b47b4eab07bf5b9ced3859f5a8b388a840b35
Reviewed-on: https://chromium-review.googlesource.com/329760
Reviewed-by: Robert Sesek <rsesek@chromium.org>
CrashpadInfo not being initialized/propagated properly on Mac.
Change-Id: I5f33a16e4e18bb1b068e0d4aeb7f2032a6cb6278
Reviewed-on: https://chromium-review.googlesource.com/324500
Reviewed-by: Mark Mentovai <mark@chromium.org>
crashpad and mini_chromium both have top-level “build” directories.
These would conflict with top-level “BUILD” files in google3 when
checked out on a case-sensitive filesystem. Although Crashpad’s “build”
directory can be moved easily, mini_chromium’s matches Chromium’s, which
is much more difficult to move. “build” is also the best and most
obvious name for these directories.
To avoid this problem, in the external-dependencies build, crashpad and
mini_chromium are placed one level deeper, just as crashpad is in
Chromium, and mini_chromium is in the standalone Crashpad build. This
allows true pristine unmodified copies to be checked in to google3,
without comingling locally-added files such as BUILD with external
source.
The directory structure adopted for the external-dependencies build is
now
root/crashpad/crashpad[/README]
root/gmock[/include/gmock/gmock.h]
root/gtest[/include/gtest/gtest.h]
root/gyp[/pylib/gyp]
root/mini_chromium/mini_chromium[/build/common.gypi]
Change-Id: Idbc8f1b0d87da0cbceab3c15e059e839c1fb6a3f
Reviewed-on: https://chromium-review.googlesource.com/323991
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This augments the standalone and in-Chromium models with an external
model, in which the dependencies and Crashpad are checked out as
siblings in the same directory, organized according to this structure:
root/crashpad[/README]
root/gmock[/include/gmock/gmock.h]
root/gtest[/include/gtest/gtest.h]
root/gyp[/pylib/gyp]
root/mini_chromium[/build/common.gypi]
This is the directory structure used in google3.
Change-Id: Ie300ead7cd085265933e4ed891509ce050e995e2
Reviewed-on: https://chromium-review.googlesource.com/324230
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
Kasko needs a way to read crash keys from out of process. This API
reuses the functionality of PEImageAnnotationsReader.
Change-Id: I2f3bbc358212e6f50235183e9dbb4e5a2cf989cf
This is a reupload of https://codereview.chromium.org/1586433003/ but
for gerrit.
Change-Id: I2f3bbc358212e6f50235183e9dbb4e5a2cf989cf
Reviewed-on: https://chromium-review.googlesource.com/322550
Reviewed-by: Scott Graham <scottmg@chromium.org>
Tested-by: Scott Graham <scottmg@chromium.org>
Reviewed-by: Scott Graham <scottmg@google.com>
It has no effect on Gerrit hosts. The notification settings within
Gerrit need to be configured.
Change-Id: I6ab9ed0d6f55742ebe934924cc9272efd7e2f3c6
BUG=
Change-Id: I592e0dcacfc41d90bf7c0e6800cd8e2c411c6c2c
Reviewed-on: https://chromium-review.googlesource.com/322190
Tested-by: Andrew Bonventre <andybons@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
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 .
This is a temporary measure to try to account for lower than expected
upload volume from Chrome in the wild. So this doesn't fix bug 23, but
is related. The ability to delimit the upload rate is useful when
testing locally too.
R=mark@chromium.org
BUG=crashpad:23
Review URL: https://codereview.chromium.org/1563683002 .
a43fee120b10 Sync Mac scopers with upstream Chromium
This adapts to updated Mac scopers from Chromium cfd6ed5600d8, including
the changes from that commit and Chromium f39d4ffc6c32.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1565873002 .
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 .
../../handler/crash_report_upload_thread.cc:142:7: error: field 'database_' will be initialized after field 'thread_' [-Werror,-Wreorder]
database_(database),
^
1 error generated.
And:
..\util\thread\worker_thread_test.cc(25) : warning C4244: 'initializing' : conversion from 'double' to 'const uint64_t', possible loss of data
BUG=crashpad:22
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1556043005 .
Fix some warnings when compiling crashpad with VC++ 2015 Update 1.
Warning 4302 occurs if you convert from a pointer to a <sizeof(void*)
integer in one cast, because this often indicates an accidental pointer
truncation which can be a bug in 64-bit builds.
Warning 4577 warns that noexcept will not be enforced, but we don't want
it to be enforced anyway, so I disabled it. The full warning is:
warning C4577: 'noexcept' used with no exception handling mode specified
termination on exception is not guaranteed. Specify /EHsc
BUG=440500
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1527803002 .
Patch from Bruce Dawson <brucedawson@chromium.org>.
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 .
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 .
The BaseName() was added because system DLLs were being reported by
GetFileVersionInfo()/VerQueryValue() as having major file versions of
6.2 instead of 10.0 on Windows 10 when accessed by full path, but not
by BaseName(). The PEImageReader gets the correct version from the
in-memory images, 10.0.
This trick didn't work on Windows XP, where two copies of comctl32.dll
were found loaded into the process, one with a major file version of
5.82 and the other with 6.0. Giving GetFileVersionInfo() the BaseName()
would result in it returning information from one of these, which would
cause the version to not match when the PEImageReader was looking at the
other.
All of these GetFileVersionInfo() quirks make me glad that we're not
using it anymore (outside of the test).
Because of the version numbers involved (NT 6.2 = Windows 8, where
GetVersion()/GetVersionEx() start behaving differently for
non-manifested applications) and the fact that GetFileVersionInfo()
and VerQueryValue() seem to report 10.0 even with full paths on Windows
10 in applications manifested to run on that OS, the BaseName() thing is
restricted to Windows 8 and higher.
TEST=crashpad_snapshot_test PEImageReader.VSFixedFileInfo_AllModules
BUG=crashpad:78
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1493933002 .
Don't call GetFileVersionInfo(), which calls LoadLibrary() to be able to
access the module's resources. Loading modules from the crashy process
into the handler process can cause trouble. The Crashpad handler
definitely doesn't want to run arbitrary modules' module initializer
code.
Since the VS_FIXEDFILEINFO needed is already in memory in the remote
process' address space, just access it from there.
BUG=crashpad:78
R=scottmg@chromium.org
Review URL: https://codereview.chromium.org/1475023004 .
