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 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>
This makes way for the addition of a struct matching Microsoft's layout
for ARM64.
Change-Id: I115f25290863e7438852691d1ec3c9324a42f7a5
Reviewed-on: https://chromium-review.googlesource.com/1152158
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Note that the current MicrodumpProcessor::Process implementation has a
bug due to the fact that it creates a local Microdump instance, and then
holds onto a pointer to the object returned by microdump.GetMemory()
which is destroyed when microdump goes out of scope. This CL fixes the
crash by making Microdump outlive MicrodumpProcessor, which is the same
pattern that Minidump/MinidumpProcessor uses.
Bug: google-breakpad:748
Change-Id: I554b46d309649cf404523722bd9ee39e17a10139
Reviewed-on: https://chromium-review.googlesource.com/720809
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
This change is resolving an issue that was caused by the combination of:
- Android system libraries being relro packed in N+.
- Breakpad dealing with relro packed libraries in a hack way.
This is a fix for http://crbug/611824.
I also found an use-after-free issue (bug in Minidump::SeekToStreamType). I disallowed the MinidumpStreamInfo copy and assign constructors and the compiler detected another similar issue in Minidump::Print. Then I disabled the copy and assign constructors for most classes in minidump.h (just in case). There are a couple of classes where I couldn't disallow them (since assign is used). This will require a small refactor so I left it out of this CL.
R=mark@chromium.org
Review URL: https://codereview.chromium.org/2060663002 .
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 .
Renaming variable mips to mips32 since mips is already defined
by the toolchain.
BUG=Compile error in Chromium
R=mark@chromium.org
Review URL: https://codereview.chromium.org/2006393004 .
Patch from Veljko Mihailovic <veljko.mihailovic@imgtec.com>.
Based on changes for ARM, ARM64 and X86, the support for
MIPS and MIPS64 is added in microdump.
TEST=microdump_stackwalk ~/microdump-mips32.dmp symbols/
BUG=microdump_stackwalk failing for mips architectures
Review URL: https://codereview.chromium.org/1731923002/
Properly handle microdump processing, when the system_log file contains an incomplete microdump section at the top. The processor will process the first complete microdump section.
R=primiano@chromium.org
Review URL: https://codereview.chromium.org/1742843002 .
G GL_VERSION|GL_VENDOR|GL_RENDERER.
The GPU version, vendor and renderer are extracted during microdump parsing and populated in the appropriate fields in the SystemInfo struct.
This is to match the changes introduced in crrev.com/1343713002 and crrev.com/1334473003
BUG=chromium:536769
R=primiano@chromium.org
Review URL: https://codereview.chromium.org/1678463002 .
the microdump. The microdump OS/arch line looks like:
O A arm 04 armv7l 3.4.0-perf-g4d6e88e #1 SMP PREEMPT Mon Mar 30 19:09:30 2015
and currently the field that says "armv7l" or "aarch64" is being used
to fill in the CPU arch field in crash. The problem is that on a
64-bit device this field *always* says "aarch64" even when running in
a 32-bit process, and so currently the crash reports for aarch64 are
a mix of 32-bit and 64-bit crashes. We should be using the first field
instead, which just says "arm" or "arm64" and reflects the actual
version of webview (32-bit or 64-bit) which is running.
BUG=
R=primiano@chromium.org
Review URL: https://codereview.chromium.org/1306983003 .
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1498 4c0a9323-5329-0410-9bdc-e9ce6186880e
The current code is relying on info->si_pid to figure out whether
the exception handler was triggered by a signal coming from the kernel
(that will re-trigger until the cause that triggered the signal has
been cleared) or from user-space e.g., kill -SIGNAL pid, which will NOT
automatically re-trigger in the next signal handler in the chain.
While the intentions are good (manually re-triggering user-space
signals), the current implementation mistakenly looks at the si_pid
field in siginfo_t, assuming that it is coming from the kernel if
si_pid == 0.
This is wrong. siginfo_t, in fact, is a union and si_pid is meaningful
only for userspace signals. For signals originated by the kernel,
instead, si_pid overlaps with si_addr (the faulting address).
As a matter of facts, the current implementation is mistakenly
re-triggering the signal using tgkill for most of the kernel-space
signals (unless the fault address is exactly 0x0).
This is not completelly correct for the case of SIGSEGV/SIGBUS. The
next handler in the chain will stil see the signal, but the |siginfo|
and the |context| arguments of the handler will be meaningless
(retriggering a signal with tgkill doesn't preserve them).
Therefore, if the next handler in the chain expects those arguments
to be set, it will fail.
Concretelly, this is causing problems to WebView. In some rare
circumstances, the next handler in the chain is a user-space runtime
which does SIGSEGV handling to implement speculative null pointer
managed exceptions (see as an example
http://www.mono-project.com/docs/advanced/runtime/docs/exception-handling/)
The fix herein proposed consists in using the si_code (see SI_FROMUSER
macros) to determine whether a signal is coming form the kernel
(and therefore just re-establish the next signal handler) or from
userspace (and use the tgkill logic).
Repro case:
This issue is visible in Chrome for Android with this simple repro case:
- Add a non-null pointer dereference in the codebase:
*((volatile int*)0xbeef) = 42
Without this change: the next handler (the libc trap) prints:
F/libc ( 595): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x487
where 0x487 is actually the PID of the process (which is wrong).
With this change: the next handler prints:
F/libc ( 595): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xbeef
which is the correct answer.
BUG=chromium:481937
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/6844002.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1461 4c0a9323-5329-0410-9bdc-e9ce6186880e
The current processor implementation is grepping for /google-breakpad(
in the logcat lines, to filter out microdump lines, which by default
look like this:
W/google-breakpad( 3728): -----BEGIN BREAKPAD MICRODUMP-----
Turns out that logcat format can vary, when passing optional arguments,
and produce something like the following:
04-13 12:30:35.563 6531 6531 W google-breakpad: -----BEGIN ...
In the latter case, the "/google-breakpad(" filter is too aggressive.
This change is relaxing it, so it is compatible also with non-default
logcat arguments.
BUG=640
R=mmandlis@chromium.org
Review URL: https://breakpad.appspot.com/2864002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1442 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
