Added
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
to the beginning of all source files that didn't have it.
This ensures that configuration options are respected in all source
files. In particular, it ensures that the defines needed to fix Large
File System issues are set before including system headers.
More generally, it ensures consistency between the source files, and
avoids the possibility of ODR violations between source files that were
including config.h and source files that were not.
Process:
Ran
find . \( -name third_party -prune \) -o \( -name '.git*' -prune \) -o \( \( -name '*.cc' -o -name '*.c' \) -exec sed -i '0,/^#include/ s/^#include/#ifdef HAVE_CONFIG_H\n#include <config.h> \/\/ Must come first\n#endif\n\n#include/' {} + \)
and then manually fixed up src/common/linux/guid_creator.cc,
src/tools/solaris/dump_syms/testdata/dump_syms_regtest.cc,
src/tools/windows/dump_syms/testdata/dump_syms_regtest.cc,
src/common/stabs_reader.h, and src/common/linux/breakpad_getcontext.h.
BUG=google-breakpad:877
Fixed: google-breakpad:877
TEST=./configure && make && make check
TEST=Did the find/sed in ChromeOS's copy, ensured emerge-hana google-breakpad
worked and had fewer LFS violations.
TEST=Did the find/sed in Chrome's copy, ensured compiling hana, windows, linux, and
eve still worked (since Chrome doesn't used config.h)
Change-Id: I16cededbba0ea0c28e919b13243e35300999e799
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4289676
Reviewed-by: Mike Frysinger <vapier@chromium.org>
sed -i '' -E -e 's/Copyright (\(c\) )?([0-9-]+),? (Google|The Chromium Authors).*(\r)?$/Copyright \2 Google LLC\4/' -e '/^((\/\/|#| \*) )?All rights reserved\.?\r?$/d' -e 's/name of Google Inc\. nor the/name of Google LLC nor the/' -e 's/POSSIBILITY OF SUCH DAMAGE$/POSSIBILITY OF SUCH DAMAGE./' $(git grep -El 'Copyright (\(c\) )?([0-9-]+),? (Google|The Chromium Authors).*$')
Plus manual fixes for src/processor/disassembler_x86.{cc,h}.
Plus some conversions from CRLF to LF line endings in .cc and .h files.
Bug: chromium:1098010
Change-Id: I8030e804eecd9f5a1ec9d66ae166efd8418c2a67
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3878302
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Instead of listing everywhere the set of architectures that do not
require/support explicit float state in their crash context, a new
GOOGLE_BREAKPAD_CRASH_CONTEXT_HAS_FLOAT_STATE preprocessor macro has
been defined.
Adding novel architectures will only require to manage the
macro definition in a single place.
Change-Id: I2732982f2cdfc9fcd2f71d6e5e122617faff9e82
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3876345
Reviewed-by: Mike Frysinger <vapier@chromium.org>
In trying to create a backend service that can process both ELF and
Mach-O binaries, I found that symbol collisions occur when trying to
link different implementations of FileID. This change puts the
different implementations into separate namespaces to avoid the
collision.
Change-Id: I15aabb222803f2ffbda15ed13e66793bae32ddce
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3421417
Reviewed-by: Mark Mentovai <mark@chromium.org>
Store the information in the exception record's exception_information
field.
Change-Id: Ie215cae2f070fdab63c3d05cc1bc4fb4b7b095fa
Reviewed-on: https://chromium-review.googlesource.com/990799
Reviewed-by: Mark Mentovai <mark@chromium.org>
memory.h shadows a system header which normally isn't a problem
because of the include paths in Breakpad, but the Firefox build
system winds up with src/common in the include path so we've had
a workaround for this for years. Renaming the file lets us get
rid of that workaround and shouldn't hurt anything.
Change-Id: I3b7c4239dc77f3b2b7cf2b572a0cad88cd7e8522
Reviewed-on: https://chromium-review.googlesource.com/723261
Reviewed-by: Mark Mentovai <mark@chromium.org>
This will allow us to provide the right information for webview renderer
crashes. At the moment the crash information for the browser process is
captured (from the debuggerd output) instead.
BUG=754715
Change-Id: I409546311b6e38fe1cf804097c18d7bb2a015d83
Reviewed-on: https://chromium-review.googlesource.com/612381
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Because we can't determine the top of userspace mappable memory
directly, we rely on the fact that the process stack is allocated at the
top of the address space (minus some randomization). Anything after that
should not count as free space.
BUG=695382
Change-Id: I68453aac9732c2bd4b87236b234518068dec6640
Reviewed-on: https://chromium-review.googlesource.com/446100
Reviewed-by: Primiano Tucci <primiano@chromium.org>
This makes the parameters stored in the MinidumpDescriptor structure
functional for minidumps, analogously to how they are applied to
microdumps.
BUG=664460
Change-Id: I7578e7a1638cea8f0445b18d4bbdaf5e0a32d808
Reviewed-on: https://chromium-review.googlesource.com/435380
Reviewed-by: Robert Sesek <rsesek@chromium.org>
In order to sanitize the stack contents we erase any pointer-aligned
word that could not be interpreted as a pointer into one of the
processes' memory mappings, or a small integer (+/-4096).
This still retains enough information to unwind stack frames, and also
to recover some register values.
BUG=682278
Change-Id: I541a13b2e92a9d1aea2c06a50bd769a9e25601d3
Reviewed-on: https://chromium-review.googlesource.com/430050
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This CL makes it possible to skip a dump if the crashing thread doesn't
have any pointers to a given module. The concrete use case is WebView
where we would like to skip generating microdump output when webview
is unreferenced by the stack and thus cannot be responsible for the
crash in a way that would be debuggable.
The range of interesting addresses is chosen by examining the process
mappings to find the one that contains a pointer that is known to be in
the right shared object (i.e. an appropriately chosen function pointer)
passed from the client.
If the extracted stack does not contain a pointer in this range, then we
do not generate a microdump. If the stack extraction fails, we still
generate a microdump (without a stack).
BUG=664460
Change-Id: If19406a13168264f7751245fc39591bd6cdbf5df
Reviewed-on: https://chromium-review.googlesource.com/419476
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Primiano Tucci <primiano@chromium.org>
The stack interest range is passed in MicrodumpExtraInfo from the client.
If the extracted stack does not contain a pointer in this range, then we
assume that this is not a WebView crash, and do not generate a microdump.
If the stack extraction fails, we still generate a microdump (without a
stack).
BUG=664460
Change-Id: Ic762497f76f074a3621c7ec88a8c20ed768b9211
Reviewed-on: https://chromium-review.googlesource.com/412781
Reviewed-by: Primiano Tucci <primiano@chromium.org>
When a crash occurs as a result of an allocation failure, it is useful
to know approximately what regions of the virtual address space remain
available, so that we know whether the crash should be attributed to
memory fragmentation, or some other cause.
BUG=525938
R=primiano@chromium.org
Review URL: https://codereview.chromium.org/1796803003 .
This preserves full build ids in minidumps, which are useful for
tracking down the right version of system libraries from Linux
distributions.
The default build id produced by GNU binutils' ld is a 160-bit SHA-1
hash of some parts of the binary, which is exactly 20 bytes:
https://sourceware.org/binutils/docs-2.26/ld/Options.html#index-g_t_002d_002dbuild_002did-292
The bulk of the changes here are to change the signatures of the
FileID methods to use a wasteful_vector instead of raw pointers, since
build ids can be of arbitrary length.
The previous change that added support for this in the processor code
preserved the return value of `Minidump::debug_identifier()` as the
current `GUID+age` treatment for backwards-compatibility, and exposed
the full build id from `Minidump::code_identifier()`, which was
previously stubbed out for Linux dumps. This change keeps the debug ID
in the `dump_syms` output the same to match.
R=mark@chromium.org, thestig@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1688743002 .
The Linux dumpers use absolute paths for shared libraries referenced by
dumps, so they fail to locate them if the crash originated in a chroot.
This CL enables callers to specify a root prefix, which is prepended to
mapping paths before opening them.
BUG=chromium:591792
TEST=make check
Review URL: https://codereview.chromium.org/1761023002/
Although strictly the GPU fingerprint is defined by the build fingerprint,
there is not currently a straightforward mapping from build fingerprint
to useful GPU / GL driver information.
In order to aid debugging of WebView crashes that occur in GL drivers,
and to better understand the range of drivers and versions for feature
blacklisting purposes, it is useful to have GPU fingerprints in breakpad
microdumps.
Landing this patch on behalf of Tobias Sargeant<tobiasjs@chromium.org>
BUG=chromium:536769
R=primiano@chromium.org, thestig@chromium.org
Review URL: https://codereview.chromium.org/1334473003 .
The PopSeccompStackFrame was introduced to deal with stack frames
originated in the legacy seccomp sandbox. The only user of that
sandbox was Google Chrome, but the legacy sandbox has been
deprecated in 2013 (crrev.com/1290643003) in favor of the new
bpf sandbox.
Removing this dead code as it has some small bound checking bug
which causes occasional crashes in WebView (which are totally
unrelated to the sandbox).
Note: this will require a corresponding change in the chromium
GYP/GN build files to roll.
BUG=665,chromium:477444
R=jln@chromium.org, mark@chromium.org, torne@chromium.org
Review URL: https://codereview.chromium.org/1299593003 .
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1492 4c0a9323-5329-0410-9bdc-e9ce6186880e
So far the microdump_writer dumped the log in logcat using the default
system log. This is simple to achieve but has some drawbacks:
1. Creates spam in the system log, pushing back other eventual useful
messages.
2. There is a high chance that the microdump gets lost if some log
spam storm happens immediately after a crash and before the log
is collected by the feedback client.
3. Since Android L, the logger is smartly throttling messages (to
reduce logcat spam). Throttling brekpad logs defeats the all
point of microdumps.
This change is conceptually very simple. Replace the use of
__android_log_write() with __android_log_buf_write(), which takes
an extra bufID argument. The main drawback is that the
__android_log_buf_write is not exported in the NDK and needs to be
dynamically looked up via dlsym.
This choice has been discussed and advocated by Android owners.
See the internal bug b/21753476.
BUG=chromium:512755
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1286063003 .
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1490 4c0a9323-5329-0410-9bdc-e9ce6186880e
Shared libraries containing Android packed relocations have a load
bias that differs from the start address in /proc/$$/maps. Current
breakpad assumes that the load bias and mapping start address are
the same.
Fixed by changing the client to detect the presence of Android packed
relocations in the address space of a loaded library, and adjusting the
stored mapping start address of any that are packed so that it contains
the linker's load bias.
For this to work properly, it is important that the non-packed library
is symbolized for breakpad. Either packed or non-packed libraries may
be run on the device; the client detects which has been loaded by the
linker.
BUG=499747
R=primiano@chromium.org, rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1189823002.
Patch from Simon Baldwin <simonb@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1459 4c0a9323-5329-0410-9bdc-e9ce6186880e
This is to add build fingerprint and product name/version to
microdumps. Conversely to what happens in the case of minidumps
with MIME fields, due to the nature of minidumps, extra metadata
cannot be reliably injected after the dump is completed.
This CL adds the plumbing to inject two optional fields plus the
corresponding tests.
BUG=chromium:410294
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1125153008
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1456 4c0a9323-5329-0410-9bdc-e9ce6186880e
A recent change in the client-side microdump write (r1404) ended up
introducing a call to new() to instantiate the line buffer that
microdump uses to dump its lines. new/malloc is a luxury we cannot
afford in a compromised context.
This change switches the line buffer to be backed by the dumper
page allocator, which on Linux/Android ends up requesting pages
via mmap.
Also, the microdump write bails out without crashing if the page
allocator failed (crash during severe OOM).
BUG=640
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1432 4c0a9323-5329-0410-9bdc-e9ce6186880e
- Filter modules by prot flags (only +x) not extensions. It wouldn't
otherwise catch the case of Chrome mapping the library from the
apk (which is mapped r-x but doesn't end in .so).
- Use compile-time detection of target arch, in order to cope with
multilib OSes, where uname() doesn't reflect the run-time arch.
- Add OS information and CPU arch / count.
- Add support for aarch64.
- Add tests and stackwalk expectations for aarch64.
- Fix a potential overflow bug in the processor.
- Rebaseline the tests using smaller symbols.
- Fix microdump_writer_unittest.cc on 32-bit host.
BUG=chromium:410294
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1407 4c0a9323-5329-0410-9bdc-e9ce6186880e
Microdumps are a very lightweight variant of minidumps. They are meant
to dump a minimal crash report on the system log (logcat on Android),
containing only the state of the crashing thread.
This is to deal with cases where the user has opted out from crash
uploading but we still want to generate meaningful information on the
device to pull a stacktrace for development purposes.
Conversely to conventional stack traces (e.g. the one generated by
Android's debuggerd or Chromium's base::stacktrace) microdumps do NOT
require unwind tables to be present in the target binary. This allows
to save precious binary size (~1.5 MB for Chrome on Arm, ~10 MB on
arm64).
More information and design doc on crbug.com/410294
BUG=chromium:410294
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1398 4c0a9323-5329-0410-9bdc-e9ce6186880e
