windows.h defines exception_code as a macro, which conflicts with our
use of the identifier in exception records. It appears that this
particular include of windows.h is not needed, so instead of undefining
the macro, I simply delete the include. Build tested with MSVC 2013.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1579623004 .
Patch from Pavel Labath <labath@google.com>.
MSVC does not have the __PTRDIFF_TYPE__ macro defined, so I use the
standard [u]intptr_t types instead. Compilation tested on windows, linux
and mac.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1571293003 .
Patch from Pavel Labath <labath@google.com>.
Due to operator precedence, the address was first cast to void*
and then incremented, which resulted in an error on windows, as
sizeof(void) is undefined and MSVC takes this seriously. Changing
the precedence to perform the addition first.
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1570843002 .
Patch from Pavel Labath <labath@google.com>.
This file is not present on windows, and it's causing build errors
there. As far as I can tell, nothing in this file actually uses
that include, so I just remove it.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1475353002 .
Patch from Pavel Labath <labath@google.com>.
Fixes the following compilation warning when using recent version of
the iOS or OS X SDK by using the recommended new API:
../../breakpad/src/common/mac/HTTPMultipartUpload.m:56:10: error: 'stringByAddingPercentEscapesUsingEncoding:' is deprecated: first deprecated in iOS 9.0 - Use -stringByAddingPercentEncodingWithAllowedCharacters: instead, which always uses the recommended UTF-8 encoding, and which encodes for a specific URL component or subcomponent since each URL component or subcomponent has different rules for what characters are valid. [-Werror,-Wdeprecated-declarations]
[key stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
^
CFURLCreateStringByAddingPercentEscapes
../../breakpad/src/common/mac/HTTPMultipartUpload.m:207:29: error: 'sendSynchronousRequest:returningResponse:error:' is deprecated: first deprecated in iOS 9.0 - Use [NSURLSession dataTaskWithRequest:completionHandler:] (see NSURLSession.h [-Werror,-Wdeprecated-declarations]
data = [NSURLConnection sendSynchronousRequest:req
^
../../breakpad/src/client/mac/handler/minidump_generator.cc:158:6: error: 'CFPropertyListCreateFromXMLData' is deprecated: first deprecated in iOS 8.0 - Use CFPropertyListCreateWithData instead. [-Werror,-Wdeprecated-declarations]
(CFPropertyListCreateFromXMLData(NULL, data, kCFPropertyListImmutable,
^
BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=675
BUG=569158
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1563223004 .
Now that all the projects we care about use git and have repos available,
switch to them and away from the old googlecode svn repos.
TEST=`gclient sync` migrated svn->git fine
TEST=`make check` still passes
TEST=manual `diff -ur` on the new/old repos shows same content
BUG=
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1560913002 .
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 .
This works around a bug in M that prevents Breakpad from using
ftruncate() in the renderer process.
To do this, skip the calls to ftruncate() when allocating bigger
minidump files and strictly depends on write() to append to the end.
It might be less efficient but this is probably less of an issue on
SD cards. It is much better than not getting crash reports.
BUG=542840
Original CL: https://codereview.appspot.com/273880044/
Original CL Author: acleung@chromium.org
Review URL: https://codereview.chromium.org/1407233016 .
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 .
This reverts commit 7ed2476eea2c2a50fd40ec3e711dcb311d472753.
This was supposed to be committed to the linux-syscall-support
project. The two CLs landing at the sametime confused me.
Note: LSS has been updated via commit 08056836f2b4a5747daff75435d10d6.
Review URL: https://codereview.chromium.org/1395743002 .
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 .
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=669R=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] 595752f623
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 .
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
