Since target_ptr is of type uint16_t* already, we don't need to scale
the byte count as the language does that for us. If it were void*, we
would need this code, but it's not.
In practice it's probably not a big deal due to how we preallocated
memory: when converting UTF8->UTF16, we'd reserve the same number of
code units, and UTF8 takes more code units per codepoint than UTF16,
so the UTF16 vector is always oversized.
When converting UTF32->UTF16, we also reserve the same number of
code units, but since one UTF32 code unit could require two UTF16
code units (for U+10000 codepoints and higher), we would probably
corrupt memory in the process. The APIs in this module don't seem
to take into account that range in general, so for now I'm only
fixing the memory corruption.
Bug: google-breakpad:768
Change-Id: Ibfaea4e866733ff8d99b505e72c500bd40d11a74
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1732888
Reviewed-by: Mark Mentovai <mark@chromium.org>
ELF modules are loaded in memory in several, possibly discontiguous,
segments. If the holes between segments are large enough, other things,
possibly other ELF modules may be mapped in that space. Crashpad
records the range of modules as the base address of the lowest mapped
segment to the high address of the highest mapped segment. This means
that when one module is mapped into a hole in another, it appears to
the Breakpad processor as overlapping modules. Module ranges are
relevant to the Breakpad processor during stackwalking for identifying
which module a particular program counter belongs to (i.e. mapping the
address to a module's text segment). This patch addresses this issue of
overlapping modules by truncating the range of the module with the
lower base address. A typical module's text segment is the first loaded
segment which would leave the text segment range unaffected. Module
producers can restrict the size of holes in their ELF modules with the
flag "-Wl,-z,max-page-size=4096", preventing other modules from being
mapped in their address range.
Properly contemplating ELF module address ranges would require
extensions to the minidump format to encode any holes.
crbug.com/crashpad/298
This patch also renames the concept of "shrinking down" (which
truncated the upper of two overlapping ranges) to "truncate upper".
Change-Id: I4599201f1e43918db036c390961f8b39e3af1849
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1646932
Reviewed-by: Mark Mentovai <mark@chromium.org>
This enables the DWARF reader to properly parse DW_AT_ranges attributes
in compilation units and functions. Code covered by a function is now
represented by a vector of ranges instead of a single contiguous range
and DW_AT_ranges entries are used to populate it. All the code and tests
that assumed functions to be contiguous entities has been updated to
reflect the change. DW_AT_ranges attributes found in compilation units
are parsed but no data is generated for them as it is not currently needed.
BUG=754
Change-Id: I310391b525aaba0dd329f1e3187486f2e0c6d442
Reviewed-on: https://chromium-review.googlesource.com/1124721
Reviewed-by: Ted Mielczarek <ted.mielczarek@gmail.com>
This struct matches the layout defined by Microsoft and replaces
Breakpad's MDRawContextARM64_Old. This CL updates the processor to
understand either the old or new structs, but clients continue to write
the old structs.
Change-Id: I8dedd9ddb2ec083b802723b9ac87beb18d98edbd
Reviewed-on: https://chromium-review.googlesource.com/1155938
Reviewed-by: Mark Mentovai <mark@chromium.org>
A recent configuration change made it necessary to run our tests on
Travis as root.
This change also increases the timeout of ParallelChildCrashesDontHang
to make it pass in Travis virtualized containers.
Bug: google-breakpad:753
Change-Id: I6ca8ff4513c6ea3e0646f22457f28b5c4fca6654
Reviewed-on: https://chromium-review.googlesource.com/890564
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This hides the need to provide mutable C strings, and unifies
existing basename calls and variations in a single location.
Change-Id: Idfb449c47b1421f1a751efc3d7404f15f8b369ca
Reviewed-on: https://chromium-review.googlesource.com/725731
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mike Frysinger <vapier@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 should have been done as part of 2b3be5
Bug: google-breakpad:746
Change-Id: I7eae33166cff238d72293e659abc90e724b365dc
Reviewed-on: https://chromium-review.googlesource.com/667102
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This is turned on in the gyp file, but not our automake build. Include
it there to make sure we don't break it and keep coverage up.
Bug: google-breakpad:360
Change-Id: If54ff04e62641b1c4a550db8a09f5ac09ff8765c
Reviewed-on: https://chromium-review.googlesource.com/665798
Reviewed-by: Mark Mentovai <mark@chromium.org>
This lets us use the flags with clang, and to add more flags easily.
Change-Id: I51bb53ffd5ab6da769cdfb422a2c88442f1ff9ad
Reviewed-on: https://chromium-review.googlesource.com/441864
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
This moves us to being warning free by default rather than being
free of some specific warnings. This doesn't turn on any new
warnings though.
Change-Id: I60bb79d1790e85ec4618b3548dad6de5d9bf8ab5
Reviewed-on: https://chromium-review.googlesource.com/438565
Reviewed-by: Mark Mentovai <mark@chromium.org>
These are /bin/sh scripts, and `source` is a bash-specific command.
Switch to the portable `.` command instead.
Change-Id: I51d8253b26aa61c130bb5fdc4789f8d623c6d9db
Reviewed-on: https://chromium-review.googlesource.com/414524
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Some test fail on recent debian with 1.7.0 due to crashes.
Change-Id: Ia25625c27968671e24826a3eeae70dbfa5c67c95
Reviewed-on: https://chromium-review.googlesource.com/412701
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The Rust compiler uses GCC C++ name mangling, but it has another layer of
encoding so abi::cxa_demangle doesn't produce great results. This patch
changes dump_syms to dump unmangled names by default so that consumers can
demangle them after-the-fact.
It also adds a tiny bit of support for linking against a Rust library I wrote
that can demangle Rust symbols nicely:
https://github.com/luser/rust-demangle-capi
BUG=
Change-Id: I63a425035ebb7ac516f067fed2aa782849ea9604
Reviewed-on: https://chromium-review.googlesource.com/402308
Reviewed-by: Mark Mentovai <mark@chromium.org>
When enabled, adding of a new range that overlaps with an existing one can be a successful operation. The range which ends at the higher address will be shrunk down by moving its start position to a higher address so that it does not overlap anymore.
This change is required to fix http://crbug/611824. The actual fix will come in a separate CL.
R=mmandlis@chromium.org
Review URL: https://codereview.chromium.org/2029953003 .
This added debug fission support.
It tries to find the dwp file from the debug dir /usr/lib/debug/*/debug
and read symbols from them.
Most of this patch comes from
https://critique.corp.google.com/#review/52048295
and some fixes after that.
The elf_reader.cc comes from TOT google code. I just
removed some google dependency.
Current problems from this patch
1: Some type mismatch: from uint8_t * to char *.
2: Some hack to find the .dwp file. (replace .debug with .dwp)
BUG=chromium:604440
R=dehao@google.com, ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1884283002 .
Doing a `make -jN check` from a fresh build breaks (and has probably been
broken for a while). linux_client_unittest_shlib is missing $(TEST_LIBS)
from its _DEPENDENCIES. The automake manual says if _DEPENDENCIES are not
specified they'll be computed from _LDADD, but we are specifying it and just
leaving out $(TEST_LIBS).
R=vapier@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1870733005 .
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 .
Linux make check is failing for mips, mips64, arm, arm64
with error:
"fatal error: mach/arm/vm_types.h: No such file or directory" in case of arm,
"../src/third_party/mac_headers/mach/machine/vm_types.h:37:2: error: #error architecture not supported" in case of mips/mips64
This was partially fixed in https://codereview.chromium.org/1645673002/.
Here excluding src/common/mac/macho_reader_unittest for hosts other than x86/x86-64.
BUG=make check failure for linux mips
TEST=make check pass
Review URL: https://codereview.chromium.org/1692933002 .
The dump_syms_mac tool only works for the system it is being built for
(it doesn't support running on ELFs for a diff target), and it builds
only for x86 currently.
If you look at the mac header:
src/third_party/mac_headers/mach/machine/vm_types.h
it will #error for non x86/arm systems, and the arm header is not in
our source tree.
Tweak the build so it's only compiled when targetting x86 systems.
BUG=chromium:579384
TEST=`make check` pass
R=ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/1645673002 .
Some systems provide prebuilt copies of gmock/gtest (such as Chromium
OS). Add a configure flag so they can take advantage of that. This
allows for a smaller checkout as they don't need to include the full
testing/ tree.
BUG=chromium:579384
TEST=`make check` passes w/--enable-system-test-libs
TEST=`make check` passes w/--disable-system-test-libs
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1638653002 .
When building with -gsplit-dwarf, the generated dwo files are left behind
even when you `make clean`. Fix that up.
BUG=chromium:579384
TEST=`./configure CXXFLAGS='-O -gsplit-dwarf' && make && make clean` removes dwo files now
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1633893002 .
The current makefile ends up building ~17 copies of the gtest/gmock
objects -- every test that refers to the cc files directly will have
its own copy. This is because the build doesn't know if CFLAGS and
such have changed between each target (and in some cases, they are).
Create a new libtesting.a target to hold a single copy of these files
and update all of the unittests to link that in. This speeds up the
build a bit especially when you aren't using ccache.
This does mean we can no longer build gtest/gmock with unique flags,
but we haven't wanted that so far, so clearly no one wants that.
BUG=chromium:579384
TEST=`make check` passes
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1633903002 .
The EXTRA_PROGRAMS knob does not automatically trigger clean up of
targets listed in it. Use CLEANFILES so we make sure `make clean`
will delete the linux_client_unittest_shlib lib.
BUG=chromium:579384
TEST=`make check` passes
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1618593002 .
This CL exports LinuxCoreDumper and ElfCoreDump in the client library. The ARC collector, which is an alternative to core2md optimized for large core dumps, needs these symbols for core dump parsing and conversion to minidump.
BUG=http://b/25773929
TEST=nm src/client/linux/libbreakpad_client.a | grep LinuxCoreDumper
Review URL: https://codereview.chromium.org/1576053002 .
libbreakpad.a pointlessly contains libdisasm.a
This looks like a left-over from when libtool was used
Since this has no useful effect (as the linker doesn't recursively search
archive members which aren't objects), anything which requires the objects in
libdisasm.a must already be linking with it, so simply remove it.
BUG=https://code.google.com/p/google-breakpad/issues/detail?id=484
Review URL: https://codereview.chromium.org/1399003002 .
Automake did not install headers under c/l/dwc, which caused
compile errors when building against an installed breakpad, since
other headers (e.g. client/linux/handler/exception_handler.h)
depended on it. This commit adds these headers to the list of
automake installed files.
R=vapier@chromium.org
Review URL: https://codereview.chromium.org/1127393006 .
We're working on building our Firefox Mac builds as a Linux cross-compile
(https://bugzilla.mozilla.org/show_bug.cgi?id=921040) and we need symbol
dumping to work. This change ports the Mac dump_syms tool to build and work
on Linux. I've tested it and it produces identical output to running the
tool on Mac.
The bulk of the work here was converting src/common/mac/dump_syms.mm and
src/tools/mac/dump_syms/dump_syms_tool.mm from ObjC++ to C++ and removing
their use of Foundation classes in favor of standard C/C++.
This won't compile out-of-the-box on Linux, it requires some Mac system
headers that are not included in this patch. I have those tentatively in
a separate patch to land in Gecko
(http://hg.mozilla.org/users/tmielczarek_mozilla.com/mc/rev/5fb8da23c83c),
but I wasn't sure if you'd be interested in having them in the Breakpad tree.
We could almost certainly pare down the set of headers included there, I
didn't spend too much time trying to minimize them (we primarily just need
the Mach-O structs and a few associated bits).
I just realized that this patch is missing updating the XCode project files
(ugh). I'll fix that up in a bit.
R=mark@chromium.org
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=543111
Review URL: https://codereview.chromium.org/1340543002 .
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
when checking exploitability rating.
Linux minidumps do not support MD_MEMORY_INFO_LIST_STREAM, meaning the
processor cannot retrieve its memory mappings. However, it has its own
stream, MD_LINUX_MAPS, which contains memory mappings specific to Linux
(it contains the contents of /proc/self/maps). This CL allows the minidump
to gather information from the memory mappings for Linux minidumps.
In addition, exploitability rating for Linux dumps now use memory mappings
instead of checking the ELF headers of binaries. The basis for the change
is that checking the ELF headers requires the minidumps to store the memory
from the ELF headers, while the memory mapping data is already present,
meaning the size of a minidump will be unchanged.
As a result, of removing ELF header analysis, two unit tests have been removed.
Arguably, the cases that those unit tests check do not merit a high
exploitability rating and do not warrant a solid conclusion that was given
earlier.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1251593007
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1476 4c0a9323-5329-0410-9bdc-e9ce6186880e
ACCESS_VIOLATION and IN_PAGE_ERROR both specify
read/write/dep flags and address. ACCESS_VIOLATION currently
reports these, but IN_PAGE_ERROR does not. This change makes
IN_PAGE_ERROR report this information as well, and also the
additional NTSTATUS value for the underlying cause.
Patch by bungeman@chromium.org
Review URL: https://breakpad.appspot.com/1794002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1441 4c0a9323-5329-0410-9bdc-e9ce6186880e
This introduces the microdump_stackwalk binary which takes advantage
of the MicrodumpProcessor to symbolize microdumps.
Its operation is identical to the one of minidump_stackwalk.
This CL, in fact, is also refactoring most of the common bits into
stackwalk_common.
BUG=chromium:410294
R=mmandlis@chromium.org
Review URL: https://breakpad.appspot.com/4704002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1405 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
This change is a pure refactoring of the common bits of minidump_writer.cc
that will be shared soon with the upcoming microdump_writer.cc.
In particular, this CL is extracting the following classes:
- ThreadInfo: handles the state of the threads in the crashing process.
- RawContextCPU: typedef for arch-specific CPU context structure.
- UContextReader: Fills out a dump RawContextCPU structure from the
ucontext struct provided by the kernel (arch-dependent).
- SeccompUnwinder: cleans out the stack frames of the Seccomp sandbox
on the supported architectures.
- MappingInfo: handles information about mappings
BUG=chromium:410294
R=mmandlis@chromium.org
Review URL: https://breakpad.appspot.com/4684002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1388 4c0a9323-5329-0410-9bdc-e9ce6186880e
Adds the interfaces for MicrodumpProcessor (very similar to
MinidumpProcessor) and corresponding unittest stubs.
These stubs are required for multi-side integration and to start
rolling the updated processor library into the dependent projects.
BUG=chromium:410294
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1372 4c0a9323-5329-0410-9bdc-e9ce6186880e
