Recently, Crash started applying quotas for crash report uploads to protect the service and its client products from misbehaving product or product version. For the protection to be effective, products need to identify themselves during report upload via URL parameters. This new code makes iOS apps using Breakpad provide the parameters automatically.
In order to sanitize the stack contents we erase any pointer-aligned
word that could not be interpreted as a pointer into one of the
processes' memory mappings, or a small integer (+/-4096).
This still retains enough information to unwind stack frames, and also
to recover some register values.
BUG=682278
Change-Id: I541a13b2e92a9d1aea2c06a50bd769a9e25601d3
Reviewed-on: https://chromium-review.googlesource.com/430050
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Follow-up CL to add relevant code to the copy constructor and assignment
operator for MinidumpDescriptor
BUG=664460
Change-Id: I71c0ad01d8686a9215a718cebc9d11a215ea342c
Reviewed-on: https://chromium-review.googlesource.com/430711
Reviewed-by: Robert Sesek <rsesek@chromium.org>
This CL makes it possible to skip a dump if the crashing thread doesn't
have any pointers to a given module. The concrete use case is WebView
where we would like to skip generating microdump output when webview
is unreferenced by the stack and thus cannot be responsible for the
crash in a way that would be debuggable.
The range of interesting addresses is chosen by examining the process
mappings to find the one that contains a pointer that is known to be in
the right shared object (i.e. an appropriately chosen function pointer)
passed from the client.
If the extracted stack does not contain a pointer in this range, then we
do not generate a microdump. If the stack extraction fails, we still
generate a microdump (without a stack).
BUG=664460
Change-Id: If19406a13168264f7751245fc39591bd6cdbf5df
Reviewed-on: https://chromium-review.googlesource.com/419476
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Commit 7a8980997d introduced additional
tests into MicrodumpWriterTest, two of which throw warnings which break
"make check" under default settings on Linux, because the Makefiles are
configured with -Werror=sign-compare.
This patch just makes the signedness of the assertion arguments match.
Change-Id: Ib522f44205c84f91bc9b93276fad60ebbf005f60
Reviewed-on: https://chromium-review.googlesource.com/418938
Reviewed-by: Tobias Sargeant <tobiasjs@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
If signal_fd is -1 still, we end up calling close(-1). Not generally
a problem, but it's bad form, and coverity is upset by it.
Change-Id: I46f9c7ca4be7b43af5b609dd8e3f03a0700af418
Reviewed-on: https://chromium-review.googlesource.com/414544
Reviewed-by: Primiano Tucci <primiano@chromium.org>
The stack interest range is passed in MicrodumpExtraInfo from the client.
If the extracted stack does not contain a pointer in this range, then we
assume that this is not a WebView crash, and do not generate a microdump.
If the stack extraction fails, we still generate a microdump (without a
stack).
BUG=664460
Change-Id: Ic762497f76f074a3621c7ec88a8c20ed768b9211
Reviewed-on: https://chromium-review.googlesource.com/412781
Reviewed-by: Primiano Tucci <primiano@chromium.org>
code.google.com is obsolete.
Fix all broken markdown links while at it.
Change-Id: I6a337bf4b84eacd5f5c749a4ee61331553279009
Reviewed-on: https://chromium-review.googlesource.com/411800
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Calling _exit() is something iOS inherited from Mac OS X Breakpad, and isn't
necessary on iOS. This is necessary because recently iOS has started
re-launching the application if breakpad catches a startup crash and calls exit
during startup.
BUG=chromium:645146
Change-Id: Ibb5a681282a886259424655aa8506a80a1fd4f4c
Reviewed-on: https://chromium-review.googlesource.com/397058
Reviewed-by: Mark Mentovai <mark@chromium.org>
Patch provided by Thomas Schweitzer.
BUG=
Change-Id: I1721db8cab7774b433ff6703a0ddc1eab6620c0b
Reviewed-on: https://chromium-review.googlesource.com/379898
Reviewed-by: Mark Mentovai <mark@chromium.org>
Fix unused variable error. Code that uses the kWaitForHandlerThreadMs
constant is inside and ifdef so in some compile configurations constant
was unused. Move it where it's used.
And do the same with other constants as requested during review.
BUG=
Change-Id: I4f4c8f36c982092d53438ed6d2a0a97772402d69
Reviewed-on: https://chromium-review.googlesource.com/374378
Reviewed-by: Mark Mentovai <mark@chromium.org>
On Linux, breakpad relies on /proc/[pid]/maps to associate symbols from
addresses. ChromeOS' hugepage implementation replaces some segments
with anonymous private pages, which is a restriction of current
implementation in Linux kernel at the time of writing. Thus, breakpad
can no longer symbolize addresses from those text segments replaced by
hugepages.
This patch tries to recover the mappings. Because hugepages are always
inserted in between some .text sections, it tries to infer the names and
offsets of the segments, by looking at segments immediately precede and
succeed them.
For example, a text segment before hugepage optimization
02001000-03002000 r-xp /opt/google/chrome/chrome
can be broken into
02001000-02200000 r-xp /opt/google/chrome/chrome
02200000-03000000 r-xp
03000000-03002000 r-xp /opt/google/chrome/chrome
BUG=crbug.com/628040
R=mark@chromium.org
Review URL: https://codereview.chromium.org/2161713002 .
Patch from Ting-Yuan (Leo) Huang <laszio@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 .
__builtin_trap() causes a SIGTRAP on arm64 (at least with GCC 4.9).
SIGTRAP is not handled by breakpad, causing crashes induced by
__builtin_trap() to be missed.
Note that on x86 and arm, instead, __builtin_trap() raises a SIGILL,
which is already handled by breakapd.
BUG=chromium:614865
R=vapier@chromium.org
Review URL: https://codereview.chromium.org/2042853002 .
src/client/linux/minidump_writer/minidump_writer.cc:273 obtains the
stack info by calling GetStackInfo(). That method will return the
stack base address, aligned to the bottom of the memory page that
'stack_pointer' is in. After that it will cap the size of the memory
area to be copied into the minidump to 'max_stack_len', starting from
the base address, if the caller requested so. This will be the case
when collecting reduced stacks, as introduced by this change:
https://breakpad.appspot.com/487002/
In such cases the caller will request 2048 bytes of memory. However
GetStackInfo() will have aligned the base address to the page
boundary, by default 4096 bytes. If the stack, which grows towards the
base address from the top ends before the 2048 bytes of the first
block, then we will not collect any useful part of the stack.
As a fix we skip chunks of 'max_stack_len' bytes starting from
the base address until the stack_pointer is actually contained in the
chunk, which we will add to the minidump file.
BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=695R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1959643004 .
Patch from Lars Volker <lv@cloudera.com>.
When a crash occurs as a result of an allocation failure, it is useful
to know approximately what regions of the virtual address space remain
available, so that we know whether the crash should be attributed to
memory fragmentation, or some other cause.
BUG=525938
R=primiano@chromium.org
Review URL: https://codereview.chromium.org/1796803003 .
Reason for revert:
It is causing breakpad crash reports to be invalid (see the associated
bug).
Merging empty holes in r-x mappings was originally introduced in
https://breakpad.appspot.com/7714003 to deal with the first generation
of relro packing, which could introduce holes within a .so mapping:
[libchrome.so]
[guard region]
[libchrome.so]
However, the logic is broken for the case of two *different* adjacent
.so mappings with a guard region in the middle:
[libfoo.so]
[guard region]
[libchrome.so]
In this case the guard region is mistakenly associated with libfoo.so,
but that is not the right thing to do. In fact, the second generation of
rerlo packing added the guard region to prevent mmaps from overlapping
and to give room for the non-zero vaddr of relro-packed libraries, which
require an anticipated load bias.
As the first generation of relro packing is not used anymore, there is
no reason to keep this buggy code, which causes failures in decoding
crashes where an arbitrary library is mapped immediately before a rerlo
packed library.
Original issue's description:
> Extend mapping merge to include reserved but unused mappings.
>
> When parsing /proc/pid/maps, current code merges adjacent entries that
> refer to the same library and where the start of the second is equal to
> the end of the first, for example:
>
> 40022000-40025000 r-xp 00000000 b3:11 827 /system/lib/liblog.so
> 40025000-40026000 r--p 00002000 b3:11 827 /system/lib/liblog.so
> 40026000-40027000 rw-p 00003000 b3:11 827 /system/lib/liblog.so
>
> When the system linker loads a library it first reserves all the address
> space required, from the smallest start to the largest end address, using
> an anonymous mapping, and then maps loaded segments inside that reservation.
> If the loaded segments do not fully occupy the reservation this leaves
> gaps, and these gaps prevent merges that should occur from occurring:
>
> 40417000-4044a000 r-xp 00000000 b3:11 820 /system/lib/libjpeg.so
> > 4044a000-4044b000 ---p 00000000 00:00 0
> 4044b000-4044c000 r--p 00033000 b3:11 820 /system/lib/libjpeg.so
> 4044c000-4044d000 rw-p 00034000 b3:11 820 /system/lib/libjpeg.so
>
> Where the segments that follow this gap do not contain executable code
> the failure to merge does not affect breakpad operation. However, where
> they do then the merge needs to occur. Packing relocations in a large
> library splits the executable segment into two, resulting in:
>
> 73b0c000-73b21000 r-xp 00000000 b3:19 786460
> /data/.../libchrome.2160.0.so
> > 73b21000-73d12000 ---p 00000000 00:00 0
> 73d12000-75a90000 r-xp 00014000 b3:19 786460
> /data/.../libchrome.2160.0.so
> 75a90000-75c0d000 rw-p 01d91000 b3:19 786460
> /data/.../libchrome.2160.0.so
>
> Here the mapping at 73d12000-75a90000 must be merged into 73b0c000-73b21000
> so that breakpad correctly calculates the base address for text.
>
> This change enables the full merge by also merging anonymous maps which
> result from unused reservation, identified as '---p' with offset 0, and
> which follow on from an executable mapping, into that executable mapping.
>
> BUG=chromium:394703
BUG=chromium:499747
R=primiano@chromium.org, rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1923383002 .
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 .
The Linux dumpers use absolute paths for shared libraries referenced by
dumps, so they fail to locate them if the crash originated in a chroot.
This CL enables callers to specify a root prefix, which is prepended to
mapping paths before opening them.
BUG=chromium:591792
TEST=make check
Review URL: https://codereview.chromium.org/1761023002/
This reverts CL https://codereview.chromium.org/1563223004/
This reverts commit 7cc0d8562bf8b20b88cc941ba72593cb7230ecf6.
CL 1563223004 introduces two bugs on iOS.
- Encoding the minidump name with extra percent causing crash server to fail
processing the file.
- Using a released pointer causing random crashes on upload. The
data, resp, err pointers returned in the NSURLSession completion
handler is released at the end of the block. When used later (to get
the crash ID), it causes a crash.
BUG=569158
R=blundell@chromium.org, mark@chromium.org
Review URL: https://codereview.chromium.org/1619603002 .
Patch from Olivier Robin <olivierrobin@chromium.org>.
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 .
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 .
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 .
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 .
