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>
The generated page’s benefit-to-complexity ratio was too low.
BUG=crashpad:138
Change-Id: I5324c33b6b7f83e973c40b256b06e25c763b23c4
Reviewed-on: https://chromium-review.googlesource.com/408268
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The strangest discovery relates to the # <h1> title in navbar.md.
Gitiles renders it small unless there’s a [home] reference, so use that.
This should only affect wrapping the site logo in the [home] link, but
it appears to control the size of the navbar title too. See
https://code.google.com/p/gitiles/issues/detail?id=130.
BUG=crashpad:138,gitiles:130
Change-Id: I11b3a79f045efa22358b3c3ef4b50ce2e6b3282e
Reviewed-on: https://chromium-review.googlesource.com/408458
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Also, update mini_chromium to 414d59602ac38e24f1e93929fda3d79d72cea139
7bfe6cd9579b README→README.md; convert plain text to Markdown
414d59602ac3 Fix mailto: link in README.md
BUG=crashpad:138
Change-Id: Ibd3c054a3e7f08a740fe6aca408cf23797d992ae
Reviewed-on: https://chromium-review.googlesource.com/408316
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Most of the world, including the Chromium universe, seems to be
standardizing on Markdown for documentation. Markdown provides the
benefit of automatic rendering on Gitiles (Gerrit), and on GitHub
mirrors as well. Crashpad should fit in with its surroundings.
There are two quirks that I was unable to resolve.
- Markdown does not allow **emphasis** within a ```code fence```
region. In blocks showing interactive examples, the AsciiDoc
documentation used this to highlight what the user was expected to
type.
- Markdown does not have a “definition list” (<dl>). This would have
been nice in man pages for the Options and Exit Status sections.
In its place, I used unnumbered lists. This is a little ugly, but
it’s not the end of the world.
The new Markdown-formatted documentation is largely identical to the
AsciiDoc that it replaces. Minor editorial revisions were made.
References to Mac OS X now mention macOS, and tool man pages describing
tools that that access task ports now mention System Integrity
Protection (SIP).
The AppEngine-based https://crashpad.chromium.org/ app in doc/appengine
is still necessary to serve Doxygen-generated documentation. This app is
updated to redirect existing generated-HTML URLs to Gitiles’ automatic
Markdown rendering.
Scripts in doc/support are updated to adapt to this change. All AsciiDoc
support files in doc/support have been removed.
BUG=crashpad:138
Change-Id: I15ad423d5b7aa1b7aa2ed1d2cb72639eec7c81aa
Reviewed-on: https://chromium-review.googlesource.com/408256
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Scott Graham <scottmg@chromium.org>
The Windows 10 loader starts a few extra threads before main(). In a few
of the test cases, the tests were relying on thread ordering (generally,
the test thread being at index #1). Instead, use other signals to find
the correct thread to verify.
R=mark@chromium.org
Change-Id: Icb1f5a8fdf3a0ea6d82ab65960dbcb650965f269
Reviewed-on: https://chromium-review.googlesource.com/407073
Reviewed-by: Mark Mentovai <mark@chromium.org>
crashpad_snapshot_test MachOImageAnnotationsReader.CrashDyld was failing
on 10.12.1. In 10.12, dyld’s intentional crashes come through
abort_with_payload(). In 10.12.1, it appears that the task port sent
along with abort_with_payload() crashes is now a corpse port, which has
a different port name than the task port that it originated from.
https://openradar.appspot.com/29079442
TEST=crashpad_snapshot_test MachOImageAnnotationsReader.CrashDyld
BUG=crashpad:137
Change-Id: I43f89c0f595dd5614fc910fa1f19f21ddf0a7c4d
Reviewed-on: https://chromium-review.googlesource.com/407087
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This defines the global (per-module) CrashpadInfo structure properly on
Linux/Android, located via the “crashpad_info” section name.
Per the ELF specification, section names with a leading dot are reserved
for the system. Reading that, I realized that the same is true of Mach-O
sections with leading underscores, so this renames the section as used
on Mach-O from __DATA,__crashpad_info to __DATA,crashpad_info.
This change is sufficient to successfully build crashpad_client as a
static library on Linux/Android, but the library is incomplete. There’s
no platform-specific database implementation, no CaptureContext() or
CRASHPAD_SIMULATE_CRASH() implementation, and most notably, no
CrashpadClient implementation.
BUG=crashpad:30
Change-Id: I29df7b0f8ee1c79bf8a19502812f59d4b1577b85
Reviewed-on: https://chromium-review.googlesource.com/406427
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Not surprisingly,
"0x278,0x27c,0x280,0x274,0x288,0x978a70,0x978a80,0x978a90" is not a
valid directory to store metrics in.
Fortunately --metrics was processed before --initial-client-data in a
local build, otherwise this could have lurked for a long time. :(
R=mark@chromium.org
BUG=655788,656800
Change-Id: I3ac3d1b487f55ddf0172bac51f8d9efc411c3329
Reviewed-on: https://chromium-review.googlesource.com/406938
Reviewed-by: Mark Mentovai <mark@chromium.org>
Second follow up to https://chromium-review.googlesource.com/c/400015/
The ideal would be that if we fail to start the handler, then we don't
end up passing through our unhandled exception filter at all.
In the case of the non-initial client (i.e. renderers) we can do this by
not setting our UnhandledExceptionFilter until after we know we've
connected successfully (because those connections are synchronous from
its point of view). We also change WaitForNamedPipe in the connection
message to block forever, so as long as the precreated pipe exists,
they'll wait to connect. After the initial client has passed the server
side of that pipe to the handler, the handler has the only handle to it.
So, if the handler has disappeared for whatever reason, pipe-connecting
clients will fail with FILE_NOT_FOUND, and will not stick around in the
connection loop. This means non-initial clients do not need additional
logic to avoid getting stuck in our UnhandledExceptionFilter.
For the initial client, it would be ideal to avoid passing through our
UEF too, but none of the 3 options are great:
1. Block until we find out if we started, and then install the filter.
We don't want to do that, because we don't want to wait.
2. Restore the old filter if it turns out we failed to start. We can't
do that because Chrome disables ::SetUnhandledExceptionFilter()
immediately after StartHandler/SetHandlerIPCPipe returns.
3. Don't install our filter until we've successfully started. We don't
want to do that because we'd miss early crashes, negating the benefit
of deferred startup.
So, we do need to pass through our UnhandledExceptionFilter. I don't
want more Win32 API calls during the vulnerable filter function. So, at
any point during async startup where there's a failure, set a global
atomic that allows the filter function to abort without trying to signal
a handler that's known to not exist.
One further improvement we might want to look at is unexpected
termination of the handler (as opposed to a failure to start) which
would still result in a useless Sleep(60s). This isn't new behaviour,
but now we have a clear thing to do if we detect the handler is gone.
(Also a missing DWORD/size_t cast for the _x64 bots.)
R=mark@chromium.org
BUG=chromium:567850,chromium:656800
Change-Id: I5be831ca39bd8b2e5c962b9647c8bd469e2be878
Reviewed-on: https://chromium-review.googlesource.com/400985
Reviewed-by: Mark Mentovai <mark@chromium.org>
Also add a link to codereview.settings.
Change-Id: Id6676e16fa3e10e34805c47b2d41e82e524af09a
Reviewed-on: https://chromium-review.googlesource.com/406707
Reviewed-by: Robert Sesek <rsesek@chromium.org>
ARCH_CPU_ARMEL, not ARCH_CPU_ARM. This is probably going to bite again.
BUG=crashpad:30
Change-Id: Ifa6069638c72db13b7f6498471f9ca3ad7c45b90
Reviewed-on: https://chromium-review.googlesource.com/406407
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The default filename rules do not match .S or .asm, so the
platform-specific assembler implementations of CaptureContext() were not
being affirmatively excluded from other platforms’ builds. This
previously worked without causing problems because the Mac build
environment didn’t know what to do with .asm files, and the Windows
build environment didn’t know what to do with .S files. Now that another
platform that may understand .S files is being added, the rules for when
to build these files must be tailored a bit more tightly.
BUG=crashpad:30
Change-Id: Ib62e619c007320d45279c104b3e229d92698aa72
Reviewed-on: https://chromium-review.googlesource.com/406348
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Also, update a few links for good measure.
Change-Id: I47113a4f324e4ad6ba02aa46bae821eefd4d98ea
Reviewed-on: https://chromium-review.googlesource.com/406347
Reviewed-by: Robert Sesek <rsesek@chromium.org>
StringToUnsignedInt[64]Traits::Convert() was returning in its failure
(negative input) case without touching *end. Its caller relies on *end
to detect failure.
Change-Id: I636f95471cd499434743e73f0e5e0b60c0871795
Reviewed-on: https://chromium-review.googlesource.com/405468
Reviewed-by: Robert Sesek <rsesek@chromium.org>
- In the ProcessInfo test, port the global argc/argv getter to Linux by
reading /proc/self/cmdline.
- Use <inttypes.h> format macros for 64-bit types.
- Only #include <sys/sysctl.h> on macOS.
- #include <signal.h> instead of <sys/signal.h>.
In order to test on Linux/Android, the following changes to the
crashpad_util_test target must be made until more porting is complete:
- Remove the dependency on crashpad_client because that library has not
been ported yet.
- Remove process_info_test.cc because it depends on crashpad_client and
there is no implementation of ProcessInfo for Linux yet.
- Remove http_transport_test.cc because there is no HTTPTransport
implementation for Linux or Android yet.
- Remove checked_address_range_test.cc because checked_address_range.cc
does not yet expose a cross-bit usable type for addresses and sizes
on Linux.
BUG=crashpad:30
TEST=crashpad_util_test
Change-Id: Ic17cf26bdf19b3eff3915bb1acdaa701f28222cd
Reviewed-on: https://chromium-review.googlesource.com/405647
Reviewed-by: Robert Sesek <rsesek@chromium.org>
- Linux (but not Android) provides __fpurge() instead of fpurge().
- In multiprocess_exec_test_child, use getrlimit(RLIMIT_NOFILE) instead
of max(sysconf(_SC_OPEN_MAX), OPEN_MAX, getdtablesize()). OPEN_MAX is
not availble on Linux (but is in Android as a bogus value), and
getdtablesize() is not available in Android since 5.0.0 (API 21).
sysconf(_SC_OPEN_MAX) and getdtablesize() both return
getrlimit(RLIMIT_NOFILE) on all relevant platforms.
- Add a Linux/Android implementation of test::Paths::Executable().
- Respect TMPDIR for all POSIX platforms in
ScopedTempDir::CreateTemporaryDirectory(). If TMPDIR is unset or
empty, use /tmp, except on Android, where /tmp does not exist and
/data/local/tmp is used instead.
Also:
- Fix the Mac and Windows implementations of test::Paths::Executable()
to abort on fatal error, in line with the new Linux/Android version.
BUG=crashpad:30
TEST=crashpad_test_test
Change-Id: I98a50d8579b193c813ba79794be087649e94cc06
Reviewed-on: https://chromium-review.googlesource.com/405507
Reviewed-by: Robert Sesek <rsesek@chromium.org>
9f129335dbe5 Add Android and ARM support to mini_chromium base
1d3e5ef89ad0 Link Linux/Android executables with -pie for position
independence
8e8d3cc9a245 Add Android to filename_rules.gypi
BUG=crashpad:30
Change-Id: Idace661e0ffa598f5c2a2a4af2d578355c101c56
Reviewed-on: https://chromium-review.googlesource.com/405567
Reviewed-by: Robert Sesek <rsesek@chromium.org>
With this change, it is possible to build crashpad_util for Android with
clang. I built with NDK 13b (clang 3.8) at API 24 (current), API 21
(used by Chrome in 64-bit builds), and API 16 (used by Chrome in 32-bit
builds).
- In WeakFileHandleFileWriter::WriteIoVec(): Android does not expose
the IOV_MAX macro, but its value can be obtained by calling
sysconf(_SC_IOV_MAX).
- In CloseMultipleNowOrOnExec(): API 21 removes getdtablesize(). Skip
it, because it returned the same thing as sysconf(_SC_OPEN_MAX),
which is already consulted.
- Throughout: Various #ifdefs checking for OS_LINUX have been extended
to also check for OS_ANDROID. In Chrome’s build_config.h (and thus
mini_chromium’s), OS_LINUX is not defined when OS_ANDROID is.
This has not been tested beyond building the crashpad_util target.
BUG=crashpad:30
Change-Id: Ieb0bed736029d2d776c534e30e534f186e6fb663
Reviewed-on: https://chromium-review.googlesource.com/405267
Reviewed-by: Robert Sesek <rsesek@chromium.org>
With this change, it is possible to build crashpad_util on Linux. I
built with clang 3.8.1 and GCC 6.2.0.
- For per-OS “exception code” metrics, Android and Linux are broken out
distinctly.
- Because Linux provides no standard UUID generator, base::RandBytes()
is used to generate random UUIDs for the InitializeWithNew() form.
- Multiple fixes for CloseMultipleNowOrOnExec():
- readdir_r() is deprecated in glibc 2.24. Use readdir() on Linux.
- Linux does not have OPEN_MAX. Use the fs.nr_open sysctl (via
/proc/sys) to determine the maximum (currently-configured)
possible number of file descriptors per process.
- Use the {CTL_KERN, KERN_MAXFILESPERPROC} sysctl on Mac to
determine the maximum (currently-configured) possible number of
file descriptors per process. This is an improvement over using
OPEN_MAX, which is still consulted.
- ThreadLogMessages’ use of DCHECK_EQ() needs an address-of operator on
function pointers to avoid confusing GCC.
One problem remains:
- util/misc/pdb_structures.h produces -Wmultichar errors. -Wmultichar
is enabled by default with GCC (but not clang). It is impossible to
disable this warning with #pragma GCC diagnostic ignored. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
This has not been tested beyond building the crashpad_util target.
BUG=crashpad:30
Change-Id: I02e7a05da512ca312806d825b3fc9b2c5bf1a990
Reviewed-on: https://chromium-review.googlesource.com/404009
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Previously, StartHandler() launched the handler process, then connected
over a pipe to register for crash handling. Instead, the initial client
can create and inherit handles to the handler and pass those handle
values and other data (addresses, etc.) on the command line.
This should improve startup time as there's no need to synchronize with
the process at startup, and allows avoiding a call to CreateProcess()
directly in StartHandler(), which is important for registration for
crash reporting from DllMain().
Incidentally adds new utility functions for string/number conversion and
string splitting.
Note: API change; UseHandler() is removed for all platforms.
BUG=chromium:567850,chromium:656800
Change-Id: I1602724183cb107f805f109674c53e95841b24fd
Reviewed-on: https://chromium-review.googlesource.com/400015
Reviewed-by: Mark Mentovai <mark@chromium.org>
Three new metrics:
- counting upload success/failure;
- enum tracking the reason upload was skipped;
- enum describing how an upload got to the pending state.
R=mark@chromium.org, asvitkine@chromium.org
BUG=crashpad:100
Change-Id: I5e0cbc1ac3424e974f3a51560e5cdad484ffc038
Reviewed-on: https://chromium-review.googlesource.com/388855
Reviewed-by: Mark Mentovai <mark@chromium.org>
Otherwise, the Chromium expansions complain about not being able to add
and needing explicit conversions.
R=mark@chromium.org
BUG=crashpad:100
Change-Id: I0540a8dabff61f2189d9532422adae5c2885ae03
Reviewed-on: https://chromium-review.googlesource.com/387166
Reviewed-by: Mark Mentovai <mark@chromium.org>
Includes mini_chromium DEPS roll for:
88e0a3e Add stub of sparse_histogram.h
R=mark@chromium.org
BUG=crashpad:100
Change-Id: I4c541a33be0f7f47e972af638d4765bd06682acf
Reviewed-on: https://chromium-review.googlesource.com/386385
Reviewed-by: Mark Mentovai <mark@chromium.org>
Solves two problems with having the macros inline:
1. Deduplicates some of the logic (in this case, the name of the
histogram, and whether it should be divided by 1024);
2. More useful check for compilation. As the macros are no-ops in
Crashpad, it was easy to use the wrong name for a variable in the
arguments to the macros (see .mm!)
This way, we have some better chance of at least having code that
compiles when built in Chromium if all the arguments are passed to
Metrics::Something() in a standalone build.
Also rolls mini_chromium DEPS to include:
99213eb Mark histogram arguments as unused to avoid warnings
R=mark@chromium.org
BUG=crashpad:100
Change-Id: I9f7fc3b85854fd61c1ebdf0084d728a7b690c2f1
Reviewed-on: https://chromium-review.googlesource.com/380445
Reviewed-by: Mark Mentovai <mark@chromium.org>
Add a first example of a UMA entry to have it available to try to plumb
through to Chromium.
Adds LoggingFileSizeByHandle() to util/file/file_io.* to retrieve the
size of on disk file to report to UMA.
Also rolls DEPS for mini_chromium to include:
b5ec9ce Add stub versions of histogram_macros.h
R=mark@chromium.org
BUG=crashpad:100
Change-Id: Ib8e96ad4b7d715b46d2c71810c95c92965a89821
Reviewed-on: https://chromium-review.googlesource.com/338821
Reviewed-by: Mark Mentovai <mark@chromium.org>
This is as a precursor to
https://chromium-review.googlesource.com/374539 which merges
MemorySnapshots and so needs to be able to update them from the minidump
code.
MinidumpMemoryWriter existed to be able to mock for tests; that
behaviour is wrapped up in TestMemorySnapshot now.
BUG=crashpad:61, chromium:638370
Change-Id: I825ec57493b12fc1848018585c14544faa7e66d4
Reviewed-on: https://chromium-review.googlesource.com/374019
Reviewed-by: Mark Mentovai <mark@chromium.org>
In order to allow on-demand uploads for crash reports, adding a
upload_explicitly_requested bit on 'pending' state and necessary support
for it.
BUG=chromium:620762
Change-Id: Ida38e483fe8d0e48eb5cbe95e8b8bfd96a2f8f00
Reviewed-on: https://chromium-review.googlesource.com/367328
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This switches the default behaviour of crashpad_handler.exe to be a
/subsystem:windows app, so that normal usage won't cause a console to be
popped up. At the same time, creates a copy of crashpad_handler.exe in
the output dir named crashpad_handler.com. The .com doesn't affect
normal operation, as the way StartHandler() uses CreateProcess()
requires a real path to a file. However, when run from a command prompt,
.com are found before .exe, so editbin the .com to be to a console app,
which will be run in preference to the exe when run as just
"crashpad_handler", as one tends to do from a command prompt when
debugging. That is:
d:\src\crashpad\crashpad\out\Debug>where crashpad_handler
d:\src\crashpad\crashpad\out\Debug\crashpad_handler.com
d:\src\crashpad\crashpad\out\Debug\crashpad_handler.exe
d:\src\crashpad\crashpad\out\Debug>crashpad_handler --help
Usage: crashpad_handler [OPTION]...
...
d:\src\crashpad\crashpad\out\Debug>crashpad_handler.exe --help
<no output>
d:\src\crashpad\crashpad\out\Debug>crashpad_handler.com --help
Usage: crashpad_handler.com [OPTION]...
...
We also use the .com file in test invocations so that output streams
will be visible.
R=mark@chromium.org
Change-Id: I1a27f88472d491b2a1d76e63c45e6415d9f679c0
Reviewed-on: https://chromium-review.googlesource.com/371578
Reviewed-by: Mark Mentovai <mark@chromium.org>
When crashy_test_program's SomeCrashyFunction is inlined into
CrashyMain, cdb doesn't demangle the decorated form of an anonymous
namespace (?A0x12345678) into the expected `anonymous namespace' string.
I experienced this in Release_x64 and Release modes using MSVS 2015
update 3 (14.0.25420.1, cl 19.00.24213.1) and cdb versions 10.0.10240.9
and 10.0.14321.1024.
BUG=crashpad:129
Change-Id: I0a665b88891c271253adccd9b2b414fcaac26c8f
Reviewed-on: https://chromium-review.googlesource.com/368730
Reviewed-by: Scott Graham <scottmg@chromium.org>
