| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is an issue in StackwalkerAMD64::GetCallerByFramePointerRecovery.
Occasionally it produces invalid frames (instruction pointer == 0) which
prevents the AMD64 stack walker from proceeding to do stack scanning and
instead leads to premature termination of the stack walking process.
For more details: http://crbug/537444
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1408973002 .
|
|
|
|
|
|
| |
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1402453006 .
|
|
|
|
|
|
|
|
|
|
|
|
| |
Debug Gecko builds don't build with -D_DEBUG, so the ifdef in
crash_generation_server doesn't work right. The MSDN documentation for
assert says that it's enabled based on the absence of the NDEBUG define,
so using that seems sensible.
R=thestig@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1398453002 .
|
|
|
|
|
|
|
|
| |
A=David Major <dmajor@mozilla.com>
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1048091
R=ted@mielczarek.org
Review URL: https://bugzilla.mozilla.org/show_bug.cgi?id=1048091 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
than 2013.
The Windows client gyp files were missing proc_maps_linux.cc for the
unittest build. Adding that revealed some build errors due to it
unconditionally including <inttypes.h>. Removing the workarounds in
breakpad_types.h (and a few other places) made that build, which means
that Visual C++ 2013 is now our minimum supported version of MSVC.
Additionally I tried building with VC++ 2015 and fixed a few warnings
(which were failing the build because we have /WX enabled) to ensure
that that builds as well.
BUG=https://code.google.com/p/google-breakpad/issues/detail?id=669
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1353893002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chrome started hitting some crashes in v8 jitted code which happens to be
non ABI compliant and debuggers (including WinDBG) are unable to produce
meaningful stack traces.
The Breakpad stack walker has some builtin heuristics to deal with such cases.
More specifically, when unable to find a good parent frame, it scans the raw
stack to find a suitable parent frame. The max scan size was set at 30
pointers which was (apparently) not enough to recover in this case.
I'm increasing it to 40 pointers. I confirmed that at 34 pointers it was able
to recover however I'm setting it to 40 in order to it some slack.
I needed to update two unittests which were expecting the previous scan limit.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1379433005 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch allows dump_syms to handle S_THREAD_LOCAL_ZEROFILL
and S_GB_ZEROFILL section in the same way as the more common
S_ZEROFILL section. Previously, dump_syms would fail to dump
a binary containing a __DATA,__thread_bss section, because it
tried to look up its data (and failed).
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1369233003 .
Patch from Pavel Labath <labath@google.com>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Android the size of the alternate stack can be very small (8k).
Even if breakpad uses sigaltstack to increase the size of the alternate
stack during initialization, that call affects only the main thread.
On Android, the libc's pthread initializer reset the sigaltstack to 8k.
When entering a signal handler, the kernel typically pushes the context
on the alternate stack. On arm64, sizeof(CrashContext) is ~5k, which
leaves 3k of usable stack for breakpad.
On top of that, breakpad allocates another struct CrashContext on the
stack. In the case of Android arm64, then, breakpad ends up using
5k + 5k > 8k of stack, which causes a stack overflow.
This got unnoticed in Android L, as the alternate stack didn't have
red-zones between them, so breakpad was often happily overflowing onto
the next thread's stack. This is not the case anymore [1].
This CL moves the CrashContext into a global variable. It should be
safe as the ExceptionHandlers are serialized on a mutex.
[1] https://android.googlesource.com/platform/bionic/+/595752f623ae88f7e4193a6e531a0805f1c6c4dc
BUG=374
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1354923002 .
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
| |
As reported in the issue tracker, building on Solaris 8 fails:
.../src/common/solaris/guid_creator.cc:69: error: extra `;'
BUG=google-breakpad:251
R=ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/1333243002 .
|
|
|
|
|
|
| |
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/1318013002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a crash occurred as a result to a write to unwritable memory, it is reason
to suggest exploitability. The processor checks for a bad write by
disassembling the command that caused the crash by piping the raw bytes near
the instruction pointer through objdump. This allows the processor to see if
the instruction that caused the crash is a write to memory and where the
target of the address is located.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1273823004
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1497 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
| |
R=ivanpe at https://codereview.chromium.org/1292503005/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1496 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Android's sys/user.h is missing user_regs_struct and user_fpsimd_struct.
Add them to the Android specific user.h used by breakpad to workaround
Android / glibc compatibility issues.
A bug has been filed on the Android NDK team to add the missing structures to
the NDK, at which point this hack can be removed.
Also remove the mxcsr_mask hack on x64, which is no longer required since
we have moved to the r10d NDK which fixes this issue.
R=primiano@chromium.org
Review URL: https://codereview.chromium.org/1291983003 .
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1495 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes the following errors shown during compile with
Windows clang:
error: cannot pass non-trivial object of type 'ATL::CComBSTR' to variadic function; expected type from format string was 'wchar_t *' [-Wnon-pod-varargs]
Original CL: https://codereview.chromium.org/1252913009/
BUG=https://code.google.com/p/google-breakpad/issues/detail?id=662
Review URL: https://codereview.chromium.org/1307463003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1494 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
| |
crrev.com/1298443002 has introduced a build failure by re-defining
__STDC_FORMAT_MACROS. Fixing it.
BUG=
R=mark@chromium.org, ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/1303493003 .
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1493 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
R=ivanpe at https://codereview.chromium.org/1298443002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1491 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r1456 introduced the possibility to customize the OS-line of the
microdump, enabling to replace, in the case of android, the generic
uname() info with the Android build fingerprint.
While doing that, it mistakenly removed the HW architecture indication
from the format.
See crbug.com/520075 for more details.
BUG=chromium:520075
R=mmandlis@chromium.org, torne@chromium.org
Review URL: https://codereview.chromium.org/1288313002 .
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1489 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
| |
This CL also consequentially adds a public method to get the number of
mappings in a Linux minidump.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1291603002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1488 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
| |
mappings when rating Linux exploitability.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1286033002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1487 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
| |
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1288323003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1486 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
| |
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1485 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
| |
R=lei at https://codereview.chromium.org/1211963002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1484 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
| |
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1280853003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1483 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
| |
MinidumpLinuxMapsList.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1287803002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1482 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
| |
contents of /proc/<pid>/maps instead of just the files mapped to memory.
Review URL: https://codereview.chromium.org/1273123002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1481 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there is a range overlap, the cause may be the client correction applied for Android packed relocations. If this is the case, back out the client correction and retry.
Patch from Simon Baldwin <simonb@chromium.org>.
https://code.google.com/p/chromium/issues/detail?id=509110
R=simonb@chromium.org
Review URL: https://codereview.chromium.org/1275173005
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1480 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
| |
On arm64 devices, GETFPREGS fails with errno==EIO. Ignore those failures
on Android arm builds.
BUG=508324
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1268023003 .
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1479 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
|
|
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1266493002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1477 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 exploitability rating for a dump is EXPLOITABILITY_NOT_ANALYZED if the
exploitability engine in not enabled, not EXPLOITABILITY_NONE.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1254333002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1475 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the order of fields in constructor initializer lists match
the order in which the fields are declared in (which is the order
they're initialized in). No intended behavior change.
This change was originally reviewed at
https://codereview.chromium.org/1230923005/
BUG=chromium:505304
TBR=thakis@chromium.org
Review URL: https://codereview.chromium.org/1234653002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1471 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
| |
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1470 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
finding the instruction/stack pointer for exploitability rating.
There was already a method that found the instruction pointer, so the files
for exploitability ratings had repeated code. Also a method for finding the
stack pointer is implemented in this CL.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1210943005
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1468 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the exception reponsible for the crash is benign, such as a floating point
exception, we can rule out the possibility that the code is exploitable. This
CL checks for such exceptions and marks the dump as not exploitable if such an
exception is found.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1212383004
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1467 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exploitability ratings.
The stackwalker will now grab the instruction pointers for ARM and ARM64
architectures, so checking exploitability on ARM and ARM64 will no longer
return EXPLOITABILITY_ERR_PROCESSING.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1216063004
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1466 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
|
|
|
|
|
|
|
|
|
|
|
|
| |
options.
I'm submitting this on behalf of Andrew Liu.
R=mmandlis@chromium.org
Review URL: https://codereview.chromium.org/1196733004
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1462 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
|