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
If a MinidumpLinuxMapsList was created and destroyed without its Read method,
the program would have a segmentation fault because the destructor did not
check for a null maps_ field. Additional changes include additional
supplementary null checks, a potential memory leak fix, and some comment
removal.
Review URL: https://codereview.chromium.org/1271543002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1478 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
The thread info expects the struct names as they expect in asm/ptrace.h,
but the header doesn't include that, it includes sys/user.h. Rename the
reg structs to match that header.
Rename the elf_siginfo to _elf_siginfo to avoid conflicting with the one
in the sys/procfs.h. It is only used locally in one place, so we don't
need to update any callers.
Otherwise, drop in aarch64 support into the minidump-2-core file.
BUG=chromium:334368
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1474 4c0a9323-5329-0410-9bdc-e9ce6186880e
When LLVM sees an attempt to dereference a NULL pointer, it will generate
invalid opcodes (undefined behavior) which leads to SIGILL which breaks
this unittest. Upstream's recommendation in this case is to add volatile
markings to get the actual dereference to happen.
This is documented in the blog post under "Dereferencing a NULL Pointer":
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1473 4c0a9323-5329-0410-9bdc-e9ce6186880e
If the minidump module containing the instruction pointer has memory
containing the ELF header and program header table, when checking the
exploitability rating, the processor will use the ELF header data to determine
if the instruction pointer lies in an executable region of the module, rather
than just checking if it lies in a module.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1233973002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1472 4c0a9323-5329-0410-9bdc-e9ce6186880e
When I first added the exception whitelist, I meant to put the check before
checking the location of the instruction pointer. (I didn't notice that it
was after the other check until now.) The whitelist check is to quickly rule
out minidumps, and if checking the instruction pointer provided any useful
information, it would be pretty indicative that the exception causing the
dump is interesting.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1211253009
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1469 4c0a9323-5329-0410-9bdc-e9ce6186880e
When changing a module's start_addr to account for Android packed
relocations, also adjust its size field so that the apparent module
end addr calculated by the breakpad processor does not alter.
Ensures that the mapping entry from a packed library is consistent
with that which an unpacked one would produce.
BUG=499747
R=primiano@chromium.org, rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1211863002.
Patch from Simon Baldwin <simonb@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1465 4c0a9323-5329-0410-9bdc-e9ce6186880e
in valid code for Linux exploitability rating.
This CL adds to the Linux exploitability checker by verifying that the
instruction pointer is in valid code. Verification is done by obtaining a
memory mapping of the crash and checking if the instruction pointer lies in
an executable region. If there is no memory mapping, the instruction pointer
is checked to determine if it lies within a known module.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1210493003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1464 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
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
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@1454 4c0a9323-5329-0410-9bdc-e9ce6186880e
Despite the fact that many places imply that sigaction and rt_sigaction
are essentially the same, rt_sigaction's signature is actually
different-- it takes the size of the kernel's sigset_t as an extra argument.
BUG=473973
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1447 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
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
On Android L+, signal and sigaction symbols are provided by libsigchain
that override the system's versions. There is a bug in these functions
where they essentially ignore requests to install SIG_DFL.
Workaround this issue by explicitly performing a syscall to
__NR_rt_sigaction to install SIG_DFL on Android.
BUG=473973
Patch by Chris Hopman <cjhopman@chromium.org>
Review URL: https://breakpad.appspot.com/1804002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1438 4c0a9323-5329-0410-9bdc-e9ce6186880e
This is a reland of the previous CL (r1433). r1433 did not achieve what
intended and failed the x86_64 build of Chrome with NDK r10c.
The workaround logic in this CL is identical to r1433, but the #define
magic is applied in a more appropriate proper place this time. Turns
out Breakpad already has an Android compatibility layer, which is
common/android/include. Piggybacking the fix there.
BUG=breakpad:642
R=fdegans@chromium.org, rmcilroy@chromium.org
Review URL: https://breakpad.appspot.com/3794002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1434 4c0a9323-5329-0410-9bdc-e9ce6186880e
r1397 did introduce a workaround to deal with a typo in sys/user.h
in the Android NDK. The typo has been fixed in [1]. However, breakpad
cannot just switch to the fixed version as this would require atomic
rolls of Breakpad and NDK in chromium, which would make reverts hard
to handle.
This change introduces an inelegant yet functional hack which makes
breakpad compatible with both versions of the NDK, with and without
the typo. It can be reverted once Chrome has stably rolled to NDK
r10d.
[1] https://android.googlesource.com/platform/bionic/+/f485547b
BUG=breakpad:642
R=fdegans@chromium.org, rmcilroy@chromium.org
Review URL: https://breakpad.appspot.com/7814002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1433 4c0a9323-5329-0410-9bdc-e9ce6186880e
