The new Linux ProcessInfo implementation uses two macros not readily
available in NDK API versions older than 21 (Android 5.0.0): NT_PRSTATUS
and PR_GETREGSET.
Chrome uses API 21 for 64-bit builds, but uses API 16 for 32-bit builds.
NT_PRSTATUS is normally defined by <elf.h> or by <linux/elf.h>, included
by <elf.h>. Although the definition in <linux/elf.h> is available in
older NDK API versions, this internal header does not mix well with
<elf.h> unless <elf.h> contemplates this combination. As of NDK API 21,
<elf.h> actually delegates most of its work to <linux/elf.h>.
PR_GETREGSET is not available in the NDK at all until API 21. Its
definition is in <linux/ptrace.h>. Most user code should #include
<sys/ptrace.h> instead, which includes <linux/ptrace.h>.
Bug: crashpad:30
Test: crashpad_util_test ProcessInfo.*
Change-Id: I4d07a9964db4665a49bde490e905ae9126880bc5
Reviewed-on: https://chromium-review.googlesource.com/455659
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
MINIDUMP_MISC_INFO_5 can carry information about extended XSTATE state
components and the process cookie value.
I made some informed guesses about the precise meanings of some of the
attributes of the XSTATE stuff.
I don’t know what “process cookie” refers to yet. My guess is that it’s
the stack canary value, or something similar. But since this isn’t an
informed guess, I haven’t written it into the documentation.
Crashpad does not yet use either of these features.
BUG=crashpad:58
Change-Id: I614568287a01fec99d6cd60e378a6d6e20b4f48c
Reviewed-on: https://chromium-review.googlesource.com/409630
Reviewed-by: Scott Graham <scottmg@chromium.org>
Commit-Queue: Mark Mentovai <mark@chromium.org>
This defines PROCESSOR_ARCHITECTURE_ARM64 and
PROCESSOR_ARCHITECTURE_ARM32_ON_WIN64, usable in
MINIDUMP_SYSTEM_INFO::ProcessorArchitecture.
This also defines four new PF_* flags usable in
CPU_INFORMATION::OtherCpuInfo::ProcessorFeatures.
Definitions are provided in compat/non_win, and #ifdef-guarded
definitions in compat/win for compatibility with Windows SDKs older than
Chrome’s minimum requirement.
PROCESSOR_ARCHITECTURE_ARM64 means the same thing that Breakpad used the
value 0x8003 for. At this point, Crashpad aims to use the
officially-defined constant. In the minidump_extensions.h
MinidumpCPUArchitecture enum, 0x8003 remains present and documented as
deprecated to discourage reuse of that constant for another purpose.
BUG=
Change-Id: Ic4b5fb9de31c5f00f3698f112633ece2a036b889
Reviewed-on: https://chromium-review.googlesource.com/409098
Reviewed-by: Scott Graham <scottmg@chromium.org>
This makes Doxygen’s output more actionable by setting QUIET = YES to
suppress verbose progress spew, and WARN_IF_UNDOCUMENTED = NO to prevent
warnings for undocumented classes and members from being generated. The
latter is too noisy, producing 721 warnings in the current codebase.
The remaining warnings produced by Doxygen were useful and actionable.
They fell into two categories: abuses of Doxygen’s markup syntax, and
missing (or misspelled) parameter documentation. In a small number of
cases, pass-through parameters had intentionally been left undocumented.
In these cases, they are now given blank \param descriptions. This is
not optimal, but there doesn’t appear to be any other way to tell
Doxygen to allow a single parameter to be undocumented.
Some tricky Doxygen errors were resolved by asking it to not enter
directiores that we do not provide documentation in (such as the
“on-platform” compat directories, compat/mac and compat/win, as well as
compat/non_cxx11_lib) while allowing it to enter the
“off-platform” directories that we do document (compat/non_mac and
compat/non_win).
A Doxygen run (doc/support/generate_doxygen.sh) now produces no output
at all. It would produce warnings if any were triggered.
Not directly related, but still relevant to documentation,
doc/support/generate.sh is updated to remove temporary removals of
now-extinct files and directories. doc/appengine/README is updated so
that a consistent path to “goapp” is used throughout the file.
Change-Id: I300730c04de4d3340551ea3086ca70cc5ff862d1
Reviewed-on: https://chromium-review.googlesource.com/408812
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Use “macOS” as the generic unversioned name of the operating system in
comments. For version-specific references, use Mac OS X through 10.6, OS
X from 10.7 through 10.11, and macOS for 10.12.
Change-Id: I1ebee64fbf79200bc799d4a351725dd73257b54d
Reviewed-on: https://chromium-review.googlesource.com/408269
Reviewed-by: Robert Sesek <rsesek@chromium.org>
RESOURCE_TYPE_IO always appears to be non-fatal based on disassembly of
the function responsible for sending it in xnu 3705.0.0.1.10 (10.12dp1
16A201w).
BUG=crashpad:120,crashpad:124
Change-Id: I9dcc6673f922cbd7af910b76991825a9d9c96fe6
Reviewed-on: https://chromium-review.googlesource.com/355250
Reviewed-by: Robert Sesek <rsesek@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 .
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 .
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 .
- Add public domain getopt implementation to third_party.
- Add timegm to compat/win.
- Add stub of strptime to compat/win.
Requires https://codereview.chromium.org/1119173003/ and
https://codereview.chromium.org/1117013006/.
Rather than working in wchar_t everywhere on Windows, convert
UTF16 command line arguments in wmain to UTF8, work primarily
in UTF8, and convert back when necessary to UTF16 for base::FilePath.
This avoids the need to genericize over all the standard C string
functions, getopt, etc. while still handling non-ASCII properly.
R=mark@chromium.org
BUG=crashpad:1
Review URL: https://codereview.chromium.org/1119783005
This adds IsExceptionNonfatalResource() and its test, and uses it in
crashpad_handler. When non-fatal resource exceptions are encountered, no
crash report is generated. crashpad_handler swallows these exceptions.
Alternatively, it could allow them to be sent to the system’s host-level
resource exception handler, normally com.apple.ReportCrash.root, which
would allow them to be processed in the same way as when Crashpad is not
in use. I’m not sure which option is better. I chose to swallow them
because there doesn’t appear to be much value in letting
com.apple.ReportCrash.root and spindump look at them.
This also moves ExcCrashRecoverOriginalException() to the new file as a
sibling of IsExceptionNonfatalResource(). This provides better
organization.
BUG=crashpad:35, chromium:474163, chromium:474326
TEST=crashpad_util_test ExceptionTypes.IsExceptionNonfatalResource
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1066243002
These two exception types use all 64 bits of the code[0] field. The
ExceptionSnapshot was unprepared to stuff this into a 32-bit field. To
resolve the discrepancy, the more-significant data is taken from the
high 32 bits of code[0]. No information is lost because the full code[0]
is made available as part of the Codes() vector.
BUG=crashpad:34
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/1050313003
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
- 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
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
compat includes headers providing definitions normally provided by the
system, in cases where the system SDK does not always provide the
correct or up-to-date definitions, and cases where code on different
platforms needs to access definitions normally only available on one
platform.
To provide definitions on a single platform, where the system SDK may
not provide the definitions correctly, use subdirectories named for the
platform, such as “mac”.
To provide definitions normally available on only one platform to
others, use subdirectories that identify that they are to be used on
platforms other than the one that originated their definitions, such as
“non_win”.
In all cases, headers should be named as they are natively in their
respective SDKs, so that it’s possible to #include them according to
their usual names.
R=rsesek@chromium.org
Review URL: https://codereview.chromium.org/432843002
