The implementations of Module/UnloadedModule and
ModuleList/UnloadedModuleList are very similar. They have been made
separate classes because they operate on different structs, complicating
factoring code into a base class and have sufficiently different
implementation that templates would not be suitable.
When unloaded modules have partially overlapping ranges, the module
shrink down feature is used to move the start of the higher range to the
end of the lower range. If two unloaded modules overlap identically, the
second module will not be added to the range map and the failure
ignored.
Places where MinidumpUnloadedModule differs from MinidumpModule:
code_identifier: the android/linux case is deleted since cv_records
never exist.
debug_file/debug_identifier/version: always return empty strings.
Read: an expected size is provided as opposed to MD_MODULE_SIZE. A
seek is used if there are extra, unused bytes.
Places where MinidumpUnloadedModuleList differs from
MinidumpModuleList:
Read: entry and header size is provided in the header in
addition to count. This changes the checks and handling of padding.
Failures from StoreRange are ignored.
GetMainModule: always returns NULL.
BUG=
Change-Id: I52e93d3ccc38483f50a6418fede8b506ec879aaa
Reviewed-on: https://chromium-review.googlesource.com/421566
Reviewed-by: Joshua Peraza <jperaza@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>
GCC6 optimizes it out, leading to crash.
Change-Id: I8425d456c1364929d135ce3860121b8098bab1f7
Reviewed-on: https://chromium-review.googlesource.com/413120
Reviewed-by: Mike Frysinger <vapier@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>
These are /bin/sh scripts, and `source` is a bash-specific command.
Switch to the portable `.` command instead.
Change-Id: I51d8253b26aa61c130bb5fdc4789f8d623c6d9db
Reviewed-on: https://chromium-review.googlesource.com/414524
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>
For more details take a look at common/using_std_string.h
BUG=
Change-Id: Ifebfc57f691ef3a3bef8cfed7106c567985edffc
Reviewed-on: https://chromium-review.googlesource.com/399738
Reviewed-by: Mark Mentovai <mark@chromium.org>
CIE looks like it's been emitted by clang since ~May 2015 [1]. This
means that we didn't have any CFI because this parse aborted, which
meant that all stack walks reverted to stack scanning. Allow expected
values for address size and segment descriptor size through so that
dump_syms can generate at least somewhat reasonable data.
[1]: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150518/277292.htmlR=mark@chromium.org
BUG=chromium:627529
Change-Id: I6dc92f51c4afd25c2adff92c09ccb8bb03bf9112
Reviewed-on: https://chromium-review.googlesource.com/406012
Reviewed-by: Mark Mentovai <mark@chromium.org>
The code has been rewriting the location of the shared lib lookup
completely which breaks normal sysroot usage with gdb. Split out
the behavior into dedicated flags so people can opt into it. You
can see examples of -i/-f in the usage() text.
We also change the -S behavior so that it's no longer enabled by
default -- if people want /var/lib/breakpad/, they can pass the -S
flag explicitly.
BUG=chromium:598947
Change-Id: Ic81726c27b4ad6c271c70696f2ac62798f07ccfb
Reviewed-on: https://chromium-review.googlesource.com/402909
Reviewed-by: Mark Mentovai <mark@chromium.org>
Found by PVS-Studio!
BUG=chromium:660198
Change-Id: I2605de2b1499f85c6e01d19e87e9eeb6af8486f3
Reviewed-on: https://chromium-review.googlesource.com/404552
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This exception is being seen in Chrome during stack unwinding.
BUG=
Change-Id: Ica3f721ca605dff835ffc3814c60bab9f6f9b192
Reviewed-on: https://chromium-review.googlesource.com/404332
Reviewed-by: Mark Mentovai <mark@chromium.org>
Always writing to stdout makes it hard to debug, and hard to use in
some script environments. Add an explicit -o flag to make it easier.
BUG=chromium:598947
Change-Id: I79667d033c8bdc8412d3a44fe3557d65f704968f
Reviewed-on: https://chromium-review.googlesource.com/403988
Reviewed-by: Mark Mentovai <mark@chromium.org>
This uses the same general framework as other minidump tools by using
getopt to parse command line options, and then passing the parsed state
around as a struct rather than via globals.
This does change the --sobasedir flag to -S because we don't support
getopt_long anywhere in the tree. Unfortunate, but better to match
all the other breakpad tools which only accept short options.
BUG=chromium:598947
Change-Id: I473081a29a8e3ef07a370848343f1a9e6681fd4e
Reviewed-on: https://chromium-review.googlesource.com/402908
Reviewed-by: Mark Mentovai <mark@chromium.org>
The Rust compiler uses GCC C++ name mangling, but it has another layer of
encoding so abi::cxa_demangle doesn't produce great results. This patch
changes dump_syms to dump unmangled names by default so that consumers can
demangle them after-the-fact.
It also adds a tiny bit of support for linking against a Rust library I wrote
that can demangle Rust symbols nicely:
https://github.com/luser/rust-demangle-capi
BUG=
Change-Id: I63a425035ebb7ac516f067fed2aa782849ea9604
Reviewed-on: https://chromium-review.googlesource.com/402308
Reviewed-by: Mark Mentovai <mark@chromium.org>
On 32-bit hosts the new code for dumping version 5 of the MDRawMiscInfo
structure uses a 32-bit left shift to select flags corresponding to the
entries in the MDXStateFeature array. Since the array is made of 64
element this automatically skipped half of it.
Change-Id: Ic4e3beaf6c56083524b33da9a396c14eec0d2bd2
Reviewed-on: https://chromium-review.googlesource.com/396107
Reviewed-by: Ted Mielczarek <ted@mielczarek.org>
EBX is sometimes used in "WIN FRAME 4" programs. Not providing the
initial value was causing the evaluation in some frames of ntdll,
resulting in a fallback to scanning and a failed stack walk.
R=mark@chromium.org
BUG=chromium:651453
Change-Id: I94a8184e1eed72b0d0e3212fe323fbdd10d56da5
Reviewed-on: https://chromium-review.googlesource.com/398059
Reviewed-by: Mark Mentovai <mark@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>
The DWARF data for Swift code has a top-level DW_TAG_module DIE as the
child of the DW_TAG_compile_unit DIE and the parent of the
DW_TAG_subprogram DIEs that dump_syms uses to locate functions.
dump_syms needs to process DW_TAG_module DIEs as introducing nested
scopes to make it work with Swift.
This also reworks demangling to be language-specific, so that the C++
demangler isn't invoked when processing Swift code. The DWARF data for
Swift code presents its mangled names in the same form as used for C++
(DW_AT_MIPS_linkage_name or DW_AT_linkage_name) but the mangling is
Swift-specific (beginning with _T instead of _Z). There is no
programmatic interface to a Swift name demangler as an analogue to C++'s
__cxa_demangle(), so mangled Swift names are exposed as-is. Xcode's
"xcrun swift-demangle" can be used to post-process these mangled Swift
names on macOS.
Support for mangled names presented in a DW_AT_linkage_name attribute,
as used by DWARF 4, is added. This supersedes the earlier use of
DW_AT_MIPS_linkage_name.
BUG=google-breakpad:702,google-breakpad:715
R=ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/2147523005 .
This allows people to use repo to manage the checkout instead of gclient.
This helps when you're used to the standard repo+gerrit workflow that the
Android & Chromium OS projects use.
Change-Id: I8b720e7995af2a1a8c9ce2ee9aa6c2638441b4a1
Reviewed-on: https://chromium-review.googlesource.com/379736
Reviewed-by: Mark Mentovai <mark@chromium.org>
Added new files elf_reader and corrected the references to dump_syms. Also some corrections to be able to build using a newer Xcode and SDK version (tested with Xcode 7.3, SDK 10.11).
Patch provided by Thomas Schweitzer.
BUG=
Change-Id: I18bd3f8ce0c1d0ceb737aee2fa8305adfcc83139
Reviewed-on: https://chromium-review.googlesource.com/377746
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>
For more details take a look at common/using_std_string.h
BUG=
Change-Id: I11f1ce697be23e13f12ea8f0468bbe02fa63c967
Reviewed-on: https://chromium-review.googlesource.com/378159
Reviewed-by: Mark Mentovai <mark@chromium.org>
Patch provided by Thomas Schweitzer.
BUG=
Change-Id: Ib35cdf766e73e4936e66f75474d83c2602f8ceb4
Reviewed-on: https://chromium-review.googlesource.com/378059
Reviewed-by: Mark Mentovai <mark@chromium.org>
instead of a specific name.
This will prevent false positives on systems which use a format such as
“[stack:69616]” for stack memory mapping names.
Change-Id: I51aeda2fe856c1f37f0d18ac06cce69fec2fffa2
Reviewed-on: https://chromium-review.googlesource.com/377086
Reviewed-by: Mike Frysinger <vapier@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>
This reverts commit 0fc6d0c8df because it
does not compile in Chromium due to the following error:
In file included from ../../breakpad/src/client/linux/minidump_writer/linux_dumper.h:43:0,
from ../../breakpad/src/client/linux/minidump_writer/minidump_writer.h:41,
from ../../breakpad/src/client/linux/handler/exception_handler.h:42,
from ../../components/crash/content/app/breakpad_linux.cc:44:
../../breakpad/src/common/android/include/link.h:46:9: error: multi-line comment [-Werror=comment]
#endif // !defined(__aarch64__) && !defined(__x86_64__) && \
^
> Don't define |r_debug| and |link_map| on Android releases 21 and later
>
> NDKs for Android 21 and later have the data structures |r_debug| and
> |link_map| defined in their header files. Defining them multiple times
> generates a compiler error.
>
> This patch protects both data structures from definition on Android 21
> and later.
>
> BUG=629088
> R=rmcilroy@chromium.org
>
> Review URL: https://codereview.chromium.org/2156173002 .
>
> Patch from Thomas Zimmermann <tzimmermann@mozilla.com>.
>
> Committed: 0ebdc4a10a
BUG=629088
Change-Id: Ia8d7d0eff060d661113e544d732813820bcb69e0
Reviewed-on: https://chromium-review.googlesource.com/367717
Reviewed-by: Mark Mentovai <mark@chromium.org>
Previously, if the input file was missing, the symupload tool on Mac
would happily process, try to parse it (calling a method on nil) and
fail when trying to create the payload to send to the server as one
of the method raised a NSInvalidArgumentException when receiving a
nil value.
Change to code to instead check the file for existence which makes it
easier to understand what is happening when part of the build system
is misconfigured and invoke symupload without first creating the symbol
file.
BUG=449348
Change-Id: Icc0f08958114da4be0cbbd7a7c2aeef905bc0db1
Reviewed-on: https://chromium-review.googlesource.com/367260
Reviewed-by: Mark Mentovai <mark@chromium.org>
NDKs for Android 21 and later have the data structures |r_debug| and
|link_map| defined in their header files. Defining them multiple times
generates a compiler error.
This patch protects both data structures from definition on Android 21
and later.
BUG=629088
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/2156173002 .
Patch from Thomas Zimmermann <tzimmermann@mozilla.com>.
Committed: 0ebdc4a10a
NDKs for Android 21 and later have the data structures |r_debug| and
|link_map| defined in their header files. Defining them multiple times
generates a compiler error.
This patch protects both data structures from definition on Android 21
and later.
BUG=629088
R=rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/2156173002 .
Patch from Thomas Zimmermann <tzimmermann@mozilla.com>.
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 .
I'd like to have the Build ID available for our symbol server
uploading, and this will make it easy.
Most of this change is me rewriting dump_symbols_unittest to be
typed tests so I could add a new test there.
R=mark@chromium.org
BUG=
Review URL: https://codereview.chromium.org/2052263002 .
__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 .
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 .
A bunch of gtest assert statements fail due to signed warnings as
unadorned constants are treated as signed integers. Mark them all
unsigned to avoid that.
One example (focus on the "[with ...]" blocks that show the types):
In file included from src/breakpad_googletest_includes.h:33:0,
from src/common/memory_unittest.cc:30:
src/testing/gtest/include/gtest/gtest.h: In instantiation of 'testing::AssertionResult testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const T2&) [with T1 = int; T2 = long unsigned int]':
src/testing/gtest/include/gtest/gtest.h:1524:23: required from 'static testing::AssertionResult testing::internal::EqHelper<true>::Compare(const char*, const char*, const T1&, const T2&, typename testing::internal::EnableIf<(! testing::internal::is_pointer<T2>::value)>::type*) [with T1 = int; T2 = long unsigned int; typename testing::internal::EnableIf<(! testing::internal::is_pointer<T2>::value)>::type = void]'
src/common/memory_unittest.cc:41:246: required from here
src/testing/gtest/include/gtest/gtest.h:1448:16: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (expected == actual) {
^
cc1plus: some warnings being treated as errors
Makefile:5180: recipe for target 'src/common/src_client_linux_linux_client_unittest_shlib-memory_unittest.o' failed
make[2]: *** [src/common/src_client_linux_linux_client_unittest_shlib-memory_unittest.o] Error 1
R=ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/2013893003 .
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>.
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 .
We tried to use common/android/include/elf.h, however it contains
'#include-next elf.h' so it still breaks MAC build. So we use
third_party/musl/include/elf.h instead.
BUG=none
TEST=make; make test passes. There is no '#include-next elf.h' in
the new elf.h
R=michaelbai@chromium.org
Review URL: https://codereview.chromium.org/1994633003 .
It's possible for `IDiaSymbol::get_name` to return S_OK and provide
and empty string. I haven't figured out the exact root cause yet
(the symbols in question are coming from the Rust standard library),
but FUNC lines with missing function names break the processor and
so we should never do it. This change makes it output "<name omitted>"
which matches the behavior of the DWARF dumping code.
R=mark@chromium.org
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1272278
Review URL: https://codereview.chromium.org/1985643004 .
This added debug fission support.
It tries to find the dwp file from the debug dir /usr/lib/debug/*/debug
and read symbols from them.
Most of this patch comes from
https://critique.corp.google.com/#review/52048295
and some fixes after that.
The elf_reader.cc comes from TOT google code. I just
removed some google dependency.
Current problems from this patch
1: Some type mismatch: from uint8_t * to char *.
2: Some hack to find the .dwp file. (replace .debug with .dwp)
BUG=chromium:604440
R=dehao@google.com, ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1884283002 .
In Android, the mmap could be overlapped by /dev/ashmem, we adjusted
the range in https://breakpad.appspot.com/9744002/, but adjusted
range isn't written back to module, this caused the corresponding
module be dropped in BasicCodeModules copy constructor.
This also fix a lot of 'unable to store module' warnings
when dumping Android's minidump.
BUG=606972
R=mark@chromium.org, wfh@chromium.org
Review URL: https://codereview.chromium.org/1939333002 .
Patch from Tao Bai <michaelbai@chromium.org>.
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 .
The x86-64 frame pointer-based unwind method will accept values
that aren't valid for the frame pointer register and the return address.
This fixes it to reject non-8-byte-aligned frame pointers, as
well as non-canonical addresses for the return address it finds.
A colleague of mine asked me why Breakpad gave a bad stack
for a crash in our crash-stats system:
https://crash-stats.mozilla.com/report/index/a472c842-2c7b-4ca7-a267-478cf2160405
Digging in, it turns out that the function in frame 0 is a leaf function,
so MSVC doesn't generate an entry in the unwind table for it, so
dump_syms doesn't produce a STACK CFI entry for it in the symbol file.
The stackwalker tries frame pointer unwinding, and %rbp is set to a
value that sort-of works, so it produces a garbage frame 1 and then
is lost. Either of the two checks in this patch would have stopped
the stackwalker from using the frame pointer.
It's possible we could do something smarter on the dump_syms side,
like enumerating all functions and outputing some default STACK CFI rule
for those that don't have unwind info, but that wouldn't fix crashes
from existing builds without re-dumping symbols for them. In any event,
these checks should always pass for valid frame pointer-using functions.
R=mark@chromium.org
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1263001
Review URL: https://codereview.chromium.org/1902783002 .
Currently an inlined function in a namespace in DWARF will
be given a name comprised of just `namespace::`. This is due
to a logic error in ComputeQualifiedName, where it doesn't
handle an empty `unqualified_name` properly.
We apparently have a fair number of these in our Mac builds,
an example of the DWARF that's being mishandled looks like:
0x117eda40: TAG_namespace [5] *
AT_name( "js" )
AT_decl_file( "../../dist/include/js/Utility.h" )
AT_decl_line( 35 )
0x11808500: TAG_subprogram [251] *
AT_low_pc( 0x0000000002f12110 )
AT_high_pc( 0x0000000002f1216b )
AT_APPLE_omit_frame_ptr( 0x01 )
AT_frame_base( rsp )
AT_abstract_origin( {0x0000000011800a4f}"_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
AT_MIPS_linkage_name( "_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
AT_name( "TraceManuallyBarrieredGenericPointerEdge" )
AT_decl_file( "/builds/slave/rel-m-rel-m64_bld-000000000000/build/js/src/gc/Marking.cpp" )
AT_decl_line( 547 )
AT_external( 0x01 )
AT_APPLE_optimized( 0x01 )
AT_inline( DW_INL_inlined )
This turned a few instances of this in the file I was testing on into
`<name omitted>`, which seems to just be a symptom of the
"DW_AT_abstract_origin comes later in the file" issue. (Which is probably
also worth fixing given that it occurs some 29k times when dumping
symbols from Firefox's XUL binary, but it's a separate issue.)
R=mark@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1887033002 .
I ran minidump_dump on a dump from Firefox on my Windows 10 machine
and noticed some streams that Breakpad didn't have names for.
Looking in minidumpapiset.h in the Windows 10 SDK finds these values
in MINIDUMP_STREAM_TYPE. There are also struct definitions for the
stream data for some of them (all but JavaScriptData), but I don't have
a particular need for those currently.
R=mark@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1884943002 .
Doing a `make -jN check` from a fresh build breaks (and has probably been
broken for a while). linux_client_unittest_shlib is missing $(TEST_LIBS)
from its _DEPENDENCIES. The automake manual says if _DEPENDENCIES are not
specified they'll be computed from _LDADD, but we are specifying it and just
leaving out $(TEST_LIBS).
R=vapier@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1870733005 .
GCC will still warn about unused return value with the form:
if (write(...));
Instead, change the semi-colon to an empty set of braces.
BUG=chromium:428478
TEST=build+test still works
It is often helpful to check if a particular symbol file dumped by
dump_syms actually matches a version of a binary file we have. The
symbol output contains an ID which can be used to see if it matches
the binary file. Unfortunately, this ID is internally calculated
and not a standard hash of the binary file. Being able to output the
header information only will allow users to determine whether their
symbol file is up to date or not.
R=jochen@chromium.org
BUG=561447
Review URL: https://codereview.chromium.org/1864823002 .
Patch from David Yen <dyen@chromium.org>.
Some projects will get build break because the comipler is confused when
searches for the standard stdio.h. Rename the wrapper file to avoid that.
renamed: src/common/stdio.h -> src/common/stdio_wrapper.h
modified: src/processor/minidump.cc
modified: src/processor/dump_context.cc
modified: src/processor/logging.cc
modified: src/processor/minidump.cc
modified: src/processor/minidump_processor.cc
modified: src/processor/stackwalk_common.cc
modified: src/processor/symbolic_constants_win.cc
R=mark@chromium.org, labath@google.com
Review URL: https://codereview.chromium.org/1864603002 .
Patch from Yunxiao Ma <yxma@google.com>.
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 .
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/
Some of the symbols in the stack trace are not found in the .dynsym
section but were located in the full symbol table .symtab section
instead. This was causing some of our stack traces to be incomplete or
point to incorrect function names.
Since we only output function names, there are actually not that many
more symbols located in .symtab that aren't in .dynsym. It is better to
simply output all symbols found so our stack traces are complete.
R=mark@chromium.org, thestig@chromium.org
BUG=561447
Review URL: https://codereview.chromium.org/1824063002 .
Patch from David Yen <dyen@chromium.org>.
The code as it stands allocates a chunk of memory of arbitrary size and places an object into it. It stores a pointer to that object and memory into a list telling the compiler that it is a pointer to a char. When the compiler deletes the objects in the list it thinks that the list contains pointers to chars - not pointers to arbitrarily sized regions of memory.
This is fixing an issue that will reproduces when the following optimization (C++ sized dealocation) is enabled: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3536.html
The fix is to explicitly call the non-sized delete operator, and the library code that supports malloc/free/new/delete will figure out the size of the block of memory from the pointer being passed in.
Patch provided by Darryl Gove.
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1788473002 .
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/
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 .
Because tools/windows/symupload/symupload.cc uses `nullptr` (which
requires VS2010), the CLSID comparison is only performed for msdia100.dll
and later. When compiling with an older (or future) CLSID_DiaSource, we
retain the existing behaviour (i.e. fail if CoCreateInstance fails).
R=ivanpe@chromium.org
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1236343
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 .
This patch changes MDCVInfoELF (which is currently unused, apparently
a vestigal bit of code landed as part of Solaris support) into a supported
CodeView format that simply contains a build id as raw bytes.
Modern ELF toolchains support build ids nicely:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/compiling-build-id.html
It would be useful to have the original build ids of loaded modules in
Linux minidumps, since tools like Fedora's darkserver allow querying by build
id and the current Breakpad code truncates the build id to the size of a GUID,
which loses information:
https://darkserver.fedoraproject.org/
A follow-up patch will change the Linux minidump generation code to produce
MDCVInfoELF in minidumps instead of MDCVInfoPDB70. This patch should be landed
first to ensure that crash processors are able to handle this format before
dumps are generated containing it.
The full build id is exposed as the return value of Minidump::code_identifier(),
which currently just returns "id" for modules in Linux dumps. For
backwards-compatibility, Minidump::debug_identifier() continues to treat
the build id as a GUID, so debug identifiers for existing modules will not
change.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1675413002 .
The method -[NSString stringByAddingPercentEscapesUsingEncoding:] has been
deprecated with 10.11 OS X SDK and 9.0 iOS SDK. The recommended method is
-[NSString stringByAddingPercentEncodingWithAllowedCharacters:] available
since 10.9 OS X SDK and 7.0 iOS SDK.
Use the new method when available using URLQueryAllowedCharacterSet to get
the same encoded string.
BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=675
BUG=569158
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1680663002 .
This updates the GYP build for the processor component (on windows).
- adds/removes references to files which were added or removed from the
repository
- includes build/common.gypi in the gyp files: needed to correctly
detect the OS (I think, the generated MSVC solutions were broken
without it)
- conditionally compiles code platform-specific code for the given
platform
After this minidump processor nearly compiles with VS2013: the generated
project is correct, but some files still have compilation errors.
Disclaimer: I have not tested the GYP changes on non-windows platform,
as there does not seem to be anyone using it there.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1643633004 .
Newer gcc versions default to -Werror=narrowing when using newer C++
standards (which we do). This causes issues when we try to stuff a
value like 0xea into a char -- the value is out of range for signed
char bytes. That's when gcc throws an error:
.../bytereader_unittest.cc: In member function 'virtual void Reader_DW_EH_PE_absptr4_Test::TestBody()':
.../bytereader_unittest.cc:400:55: error: narrowing conversion of '234' from 'int' to 'char' inside { } [-Wnarrowing]
BUG=chromium:579384
TEST=`make check` passes
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1605153004 .
Some systems provide prebuilt copies of gmock/gtest (such as Chromium
OS). Add a configure flag so they can take advantage of that. This
allows for a smaller checkout as they don't need to include the full
testing/ tree.
BUG=chromium:579384
TEST=`make check` passes w/--enable-system-test-libs
TEST=`make check` passes w/--disable-system-test-libs
R=thestig@chromium.org
Review URL: https://codereview.chromium.org/1638653002 .
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>.
The std::getline function always returns its first arg (which is an
iostream object) and cannot return anything else. Thus, testing its
value is pointless, and even leads to build errors w/at least gcc-5
due to gtest ASSERT_TRUE funcs only taking bool types:
.../exploitability_unittest.cc: In member function 'virtual void {anonymous}::ExploitabilityLinuxUtilsTest_DisassembleBytesTest_Test::TestBody()':
.../exploitability_unittest.cc:200:136: error: no matching function for call to 'testing::AssertionResult::AssertionResult(std::basic_istream<char>&)'
In file included from .../breakpad_googletest_includes.h:33:0,
from .../exploitability_unittest.cc:35:
.../gtest.h:262:12: note: candidate: testing::AssertionResult::AssertionResult(bool)
Since we know this never fails, simply drop the ASSERT_TRUE usage.
The next line already checks the content of the buffer we read.
Further on in the file, we hit some signed warnings:
In file included from .../breakpad_googletest_includes.h:33:0,
from .../exploitability_unittest.cc:35:
.../gtest.h: In instantiation of 'testing::AssertionResult testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const T2&) [with T1 = long unsigned int; T2 = int]':
.../gtest.h:1484:23: required from 'static testing::AssertionResult testing::internal::EqHelper<lhs_is_null_literal>::Compare(const char*, const char*, const T1&, const T2&) [with T1 = long unsigned int; T2 = int; bool lhs_is_null_literal = false]'
.../exploitability_unittest.cc:241:289: required from here
.../gtest.h:1448:16: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (expected == actual) {
This is because we compare the register value (a uint64_t) directly to
an integer constant, and those are signed by default. Stick a U suffix
on them to fix things up.
BUG=chromium:579384
TEST=`make check` passes
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1611763002 .
Older versions of MSVC don't have a snprintf functions. Some files
were already working around that, but not all of them. Instead of
copying the logic into every file, I centralize it into a new
stdio.h wrapper file and make other files include that.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1602563003 .
Patch from Pavel Labath <labath@google.com>.
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 .
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 .
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
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
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
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
A recent change in the client-side microdump write (r1404) ended up
introducing a call to new() to instantiate the line buffer that
microdump uses to dump its lines. new/malloc is a luxury we cannot
afford in a compromised context.
This change switches the line buffer to be backed by the dumper
page allocator, which on Linux/Android ends up requesting pages
via mmap.
Also, the microdump write bails out without crashing if the page
allocator failed (crash during severe OOM).
BUG=640
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1432 4c0a9323-5329-0410-9bdc-e9ce6186880e
This feature is enabled only when "-s" is provided as a commandline option.
minidump_stackwalk.cc:
- Add a new commandline option "-s" to output stack contents.
- Instantiate Minidump object in PrintMinidumpProcess() to keep it alive longer so that accessing process_state.thread_memory_regions() in stackwalk_common.cc doesn't result in use-after-free.
stackwalk_common.cc:
- Add a new function PrintStackContents() to output stack contents.
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/9774002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1429 4c0a9323-5329-0410-9bdc-e9ce6186880e
A computation in the stack unwind algorithm could cause an overflow if a base
pointer read from crashed process is sufficiently close to top of address space.
This causes a memory read that causes the dump thread to crash, resulting in a
failure to generate crash dump. Check fixed to properly detect that this pointer
is greater than actual memory range of current stack.
Patch by Kyle Joswiak <kjoswiak@chromium.org>
Review URL: https://breakpad.appspot.com/3754003/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1425 4c0a9323-5329-0410-9bdc-e9ce6186880e
When LinuxCoreDumper fails to copy process data from a core file, it
fills the return buffer with a repeated sequence of a special marker.
However, MinidumpWriter doesn't know about that and may incorrectly
interpret the data. In many cases, MinidumpWriter simply copies the
gibberish data to the minidump, which isn't too bad. However, the
gibberish data may cause MinidumpWriter to behave badly in some other
cases. For example, when MinidumpWriter tries to iterate through the
linked list of all loaded DSOs via the r_map field of a r_debug struct,
if the linked list is filed with the special marker, the code keeps
iterating through the same address.
This CL addresses the issue by having LinuxCoreDumper::CopyFromProcess()
returns a Boolean value to indicate if the expected data is found from
the core file. MinidumpWriter can then decide how to handle that.
BUG=chromium:453484
TEST=Run core2md with the test data attached to chromium:453484.
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/4724002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1420 4c0a9323-5329-0410-9bdc-e9ce6186880e
problems.
- The ordering of keys in stl containers cannot change. Make the relevant
members const to guarantee this assumption.
- Add handling and logging for demangle errors.
- Fix a potential double-delete bug if a function passed to AddFunction() is
already present.
BUG=chromium:449214
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/10704002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1415 4c0a9323-5329-0410-9bdc-e9ce6186880e
gcc has a single exception setting for all languages. Saying -fno-exceptions
in gcc disables exceptions and cleanups for cc files, but has no effect for mm
files.
In clang, -fno-exceptions only disables c++ exceptions, but keeps objective-c
exceptions and cleanups enabled.
http://llvm.org/viewvc/llvm-project?view=revision&revision=220714 changed
__EXCEPTIONS to be defined for clang when cleanups are enabled, independent of
if c++ exceptions are enabled. (This was necessary to have clang work with
glibc which looks at __EXCEPTIONS to decide if cleanups are enabled.)
Breakpad tried to use __EXCEPTIONS to figure out if c++ exceptions are enabled.
In cc files, this works: -fno-exceptions will disable c++ exceptions and
cleanups. But in mm files, -fno-exceptions will disable c++ exceptions and
objective-c exceptions will still be enabled, and so cleanups must run and hence
__EXCEPTIONS is defined.
To make things work with both old and new compilers, do the try/catch hack in
mm files either if __EXCEPTIONS is not defined (for old compilers) or if the
compiler is clang and __has_feature(cxx_exceptions) isn't set (which will work
for new clangs too, and which cleanly maps to if c++ exceptions are enabled).
Patch by Nico Weber <thakis@chromium.org>
Review URL: https://breakpad.appspot.com/1774002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1409 4c0a9323-5329-0410-9bdc-e9ce6186880e
Previously, dump_syms did not handle DW_FORM_ref_addr if it appeared
in DWARF 4 debugging info.
Also fix a DW_FORM_ref_addr case so that it doesn't fall through to
the next switch case when assertions are disabled and the DWARF
version isn't recognised.
The following steps will reproduce the problem when using LLVM 3.4:
cat <<END >example1.c
int main() { return 0; }
END
cat <<END >example2.c
void foo(int x) {}
END
clang -emit-llvm -g -c example1.c -o example1.bc
clang -emit-llvm -g -c example2.c -o example2.bc
llvm-link-3.4 example1.bc example2.bc -o combined.bc
clang combined.bc -o executable
./google-breakpad/build/src/tools/linux/dump_syms/dump_syms executable
When using LLVM bitcode linking in this way, LLVM's backend generates
partially-merged DWARF debugging info in which some of the references
to the "int" type go via "DW_FORM_ref_addr". Since PNaCl uses LLVM
bitcode linking, this dump_syms failure occurs with nexes produced by
the PNaCl toolchain.
BUG= https://code.google.com/p/chromium/issues/detail?id=416368
TEST= see above
R=mark@chromium.org, mcgrathr@chromium.org
Review URL: https://breakpad.appspot.com/5744002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1408 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
and updating minidump_stackwalk to show process uptime.
I tested this with a minidump from Chrome and I got a result that
is inline with what the Windows debugger is showing for that dump:
minidump_stackwalk output:
--------------------------
Process uptime: 601 seconds
WinDBG output:
--------------
Process Uptime: 0 days 0:10:01.000
I didn't update the machine readable output of minidump_stackwalk
on purpose in order to avoid breaking someone that uses it.
It can be added later to the machine output if needed.
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/7754002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1406 4c0a9323-5329-0410-9bdc-e9ce6186880e
This introduces the microdump_stackwalk binary which takes advantage
of the MicrodumpProcessor to symbolize microdumps.
Its operation is identical to the one of minidump_stackwalk.
This CL, in fact, is also refactoring most of the common bits into
stackwalk_common.
BUG=chromium:410294
R=mmandlis@chromium.org
Review URL: https://breakpad.appspot.com/4704002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1405 4c0a9323-5329-0410-9bdc-e9ce6186880e
Adding an optional parameter --product to symupload.exe. If specified it will be passed to the symbol server as POST parameter 'product'.
As part of this, I'm also fixing:
- Removed the .vcproj file as it can be generated from the .gyp file on demand.
- error C4335: Mac file format detected. Fixed the line endings for omap.cc and dia_util.cc.
- warning C4003: not enough actual parameters for macro 'max'
Symupload.exe was compiled using MSVS 2013 and DIA SDK 12.0.
Review URL: https://breakpad.appspot.com/9734002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1402 4c0a9323-5329-0410-9bdc-e9ce6186880e
Microdumps are a very lightweight variant of minidumps. They are meant
to dump a minimal crash report on the system log (logcat on Android),
containing only the state of the crashing thread.
This is to deal with cases where the user has opted out from crash
uploading but we still want to generate meaningful information on the
device to pull a stacktrace for development purposes.
Conversely to conventional stack traces (e.g. the one generated by
Android's debuggerd or Chromium's base::stacktrace) microdumps do NOT
require unwind tables to be present in the target binary. This allows
to save precious binary size (~1.5 MB for Chrome on Arm, ~10 MB on
arm64).
More information and design doc on crbug.com/410294
BUG=chromium:410294
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1398 4c0a9323-5329-0410-9bdc-e9ce6186880e
This change introduces the necessary glue typedefs to deal with the
mismatch introduced by the latest Android NDK (w.r.t. desktop Linux):
- [x86_64] Rename fpregs mxcr_mask -> .mxcsr_mask
- [mips] uc_mcontext.fpregs.fp_r.fp_dregs -> uc_mcontext.fpreg
- [mips] restore the forked user.h
Submitting this on behalf of fdegans@chromium.orgTBR=mark@chromium.org
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1397 4c0a9323-5329-0410-9bdc-e9ce6186880e
Prior to NDK r10c, Breakpad was privately backporting these system
headers. This change is now unforking and removing those headers and
using the ones from the NDK.
Rationale:
- They are finally available in the NDK, so there is no need to keep
maintaining a fork (which was necessary up until recently to support
arm64).
- These forked headers, as they are today, are not compatible with the
latest NDK (i.e. this change is required to roll NDK r10c).
The forked ucontext.h, being removed by this CL, depends on some
transitional features which are not compatible with the NDK release
being targeted here.
After this change, the NDK r10c is now required to build Breakpad on
Android. Note that NDK releases are backwards compatible and contain all
the previous API levels, so this change is NOT effectively enforcing to
build against any particular Android SDK.
Submitting this on behalf of fdegans@chromium.org
BUG=chromium:358831
R=mark@chromium.org, primiano@chromium.org, rmcilroy@chromium.org
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1396 4c0a9323-5329-0410-9bdc-e9ce6186880e
This is a refactoring of the logic which determines the
module name and path for a given MappingInfo in minidump_writer.cc.
Such logic, which will be soon shared also with the upcoming
microdump_writer.cc, is simply being moved to linux_dumper.cc,
extracting a GetMappingEffectiveNameAndPath method.
No behavioral change is intended.
BUG=chromium:410294
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/7734002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1392 4c0a9323-5329-0410-9bdc-e9ce6186880e
Server is used is done by subtracting the crashing process creation time from
the current time when the crash is generated:
uptime = now - process_creation_time
There was a bug and instead of the process creation time the code was using the
time when the process was registered with the Crash Generation Server.
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/1744002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1391 4c0a9323-5329-0410-9bdc-e9ce6186880e
This change is a pure refactoring of the common bits of minidump_writer.cc
that will be shared soon with the upcoming microdump_writer.cc.
In particular, this CL is extracting the following classes:
- ThreadInfo: handles the state of the threads in the crashing process.
- RawContextCPU: typedef for arch-specific CPU context structure.
- UContextReader: Fills out a dump RawContextCPU structure from the
ucontext struct provided by the kernel (arch-dependent).
- SeccompUnwinder: cleans out the stack frames of the Seccomp sandbox
on the supported architectures.
- MappingInfo: handles information about mappings
BUG=chromium:410294
R=mmandlis@chromium.org
Review URL: https://breakpad.appspot.com/4684002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1388 4c0a9323-5329-0410-9bdc-e9ce6186880e
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
R=rmcilroy@chromium.org, thestig@chromium.org
Review URL: https://breakpad.appspot.com/7714003
Patch from Simon Baldwin <simonb@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1380 4c0a9323-5329-0410-9bdc-e9ce6186880e
processing upcoming implementation.
dump_context.cc and dump_object.cc added in r/1370
microdump_processor.cc and microdump_processor_unittest.cc added in
r/1372
BUG=chromium:410294
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1373 4c0a9323-5329-0410-9bdc-e9ce6186880e
Adds the interfaces for MicrodumpProcessor (very similar to
MinidumpProcessor) and corresponding unittest stubs.
These stubs are required for multi-side integration and to start
rolling the updated processor library into the dependent projects.
BUG=chromium:410294
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1372 4c0a9323-5329-0410-9bdc-e9ce6186880e
This CL adds three features that will allow the client to upload the report
file.
Three main modifications are made :
- Allow upload url to have a file:// scheme, and write the HTTP request to file
in that case
- Split the request in two parts in case of a file:// scheme, the request
time and the response time. A new API [handleNetworkResponse] is added.
- Give the opportunity to the client to get the configuration NSDictionary
to be able to recreate the breakpad context at response time.
Patch by Olivier Robin <olivierrobin@chromium.org>
Review URL: https://breakpad.appspot.com/2764002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1368 4c0a9323-5329-0410-9bdc-e9ce6186880e
Using the vm_region_recurse API with a vm_region_submap_info_64
structure leads to a deviation in the structure when reading the user_tag
field.
Switching to the vm_region_recurse_64 API.
Patch by Olivier Robin <olivierrobin@chromium.org>
BUG=crbug/397133
Review URL: https://breakpad.appspot.com/4664002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1363 4c0a9323-5329-0410-9bdc-e9ce6186880e
This adds a new |-g <dSYM path>| flag to dump_syms, to specify the dSYM path for
the target Mach-O argument. The UUIDs and architectures of the two paths must
match in order to dump symbols for this "split module."
This reason for this is that for x86_64 binaries on OS X, the CFI data is stored
in the __TEXT,__eh_frame segment of the Mach-O file, and the data is not copied
into the dSYM by dsymutil. Therefore, just dumping the dSYM doesn't yield CFI
data for x86_64 files, and both the dSYM and the Mach-O file must be dumped in
order to produce a complete Breakpad symbol file. For i386 binaries, the CFI data
is stored in the __DWARF,__debug_frame segment, which is part of the dSYM, so
this isn't necessary.
BUG=https://code.google.com/p/chromium/issues/detail?id=393594R=mark@chromium.org
Review URL: https://breakpad.appspot.com/6704002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1359 4c0a9323-5329-0410-9bdc-e9ce6186880e
This GYP-ifies the src/processor and src/common directories on those platforms
as well. The Makefile build uses much more granular unittest executables, so
the new processor_unittests does not yet link because of multiple main() symbols,
but this will be fixed later.
Update issue 575
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/10674002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1358 4c0a9323-5329-0410-9bdc-e9ce6186880e
PageAllocator maps memory via sys_mmap(), implemented in
linux_syscall_support.h. We need to explicitly inform MSan that this memory is
initialized.
Patch by Sergey Matveev <earthdok@chromium.org>
BUG=chromium:394028
Review URL: https://breakpad.appspot.com/2744002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1356 4c0a9323-5329-0410-9bdc-e9ce6186880e
This patch makes two changes to breakpad to enable crash reporting to work correctly when the library is inside another file (an archive):
- Do not filter mappings which map an executable at a non-zero offset.
- If such an executable is mapped look in the ELF information for the
shared object name and use that name in the minidump.
Note this change doesn't care about the archive format and isn't Android
specific (though loading the shared library this way is currently only done on Android).
BUG=390618
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/7684002
Patch from Anton Carver <anton@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1355 4c0a9323-5329-0410-9bdc-e9ce6186880e
__system_property_get has been removed from the Android NDK for 'L' so Breakpad
no longer links. This CL just removes the call in WriteOSInformation because
Chrome already passes the build fingerprint as a crash key called "android_build_fp" in the crash report HTTP POST message.
BUG=394841,393903
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/1694002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1351 4c0a9323-5329-0410-9bdc-e9ce6186880e
After handling an uncaught NSException, release the Breakpad object
so there will not be a second crash dump logged.
Prior to this change, for every uncaught NSException handled through
the Breakpad::UncaughtExceptionHandler(), a second crash without
any useful information (generally __cxa_rethrow and std::__terminate)
is recorded.
R=qsr@chromium.org
Review URL: https://breakpad.appspot.com/9664002
Patch from Peter Lee <pkl@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1344 4c0a9323-5329-0410-9bdc-e9ce6186880e
This bug manifests itself on Android x64 (in ExceptionHandlerTest::ExternalDumper), but is possible on any platform.
The compiler is unaware of the code which runs in the signal handler which reads this variable. Without volatile the compiler is free to optimise away writes to this variable which it believes are never read.
BUG=381142, 346626
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/8664002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1343 4c0a9323-5329-0410-9bdc-e9ce6186880e
- Convert time_t values to UTC correctly. It is incorrect to cast a uint32_t*
to time_t* because the two types may have different widths. This is the
case on many 64-bit systems, where time_t is a 64-bit signed integer.
Conversion is unified in a single function, and additional uses of time_t
in minidump files not previously displayed in UTC are now displayed.
- Interpret the IMAGE_DEBUG_MISC structure correctly.
- When printing MINIDUMP_SYSTEM_INFO structures, always show the "x86" side
of the union, and state whether it's expected to be valid. (Existing
Breakpad-produced non-Windows minidumps for x86_64 use the "x86" side of
union, but Windows minidumps for x86_64 use the "other" side, so I want to
print both.)
R=ivanpe@chromium.org
Review URL: https://breakpad.appspot.com/5674002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1339 4c0a9323-5329-0410-9bdc-e9ce6186880e
This fixes exception_handler.cc:77:8: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
char protected_buffer[PAGE_SIZE] __attribute__((aligned(PAGE_SIZE)));
BUG=None
TEST=breakpad builds on ios8
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/9654002
Patch from Justin Cohen <justincohen@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1338 4c0a9323-5329-0410-9bdc-e9ce6186880e
This CL introduces "--sobasedir" command-line option to minidump-2-core.
By default, paths to shared lib files included in generated core file are
formatted as "/var/lib/breakpad/[GUID]libFoobar.so". By using "--sobasedir",
this will be "[user-supplied-path]libFoobar.so".
This option can be used to ease debugging minidump files from developer's local
builds. By specifying "minidump-2-core --sobasedir `pwd`/out/Debug/lib/
foobar.mdmp", user can load the generated core file in gdb without setting up
the symlinks for "/var/lib/breakpad".
BUG=None
A=kouhei@chromium.org
Original code review: https://breakpad.appspot.com/1214002/R=kouhei@chromium.org
Review URL: https://breakpad.appspot.com/1584002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1317 4c0a9323-5329-0410-9bdc-e9ce6186880e
This has a substantial performance improvement over using the getSymbolsByAddr iterator, especially on certain 64bit DLLS. e.g. Time to process chrome_child.dll drops from 51 minutes to 21 secs.
Note: new test data looks different because the ordering of lines is no longer by memory address. This does not affect processing. The test data has been manually compared to old data and matches (except additional PUBLIC symbols). Also, INFO lines are omitted because the source executable files are not checked in, so they are unavailable.
R=ivanpe@chromium.org, mark@chromium.org
Review URL: https://breakpad.appspot.com/1574002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1316 4c0a9323-5329-0410-9bdc-e9ce6186880e
After r1299, the LinuxCoreDumperTest::VerifyDumpWithMultipleThreads and
ElfCoreDumpTest::ValidCoreFile would both hang on Android. This appears to be due to the tkill
signal not being recieved by the thread which is meant to crash, even though tkill returns 0.
This CL retries sending the tkill signal multiple times, which prevents the Hang.
BUG=579
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/1524002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1313 4c0a9323-5329-0410-9bdc-e9ce6186880e
As part of that:
- Updated MSSymbolServerConverter to also download the executable files from the symbol server and pass them to the PDBSourceLineWriter as it is required for successful conversion of symbols for 64-bit modules.
- Added a .gyp file and target for the ms_symbol_server_converter library.
- Updated PDBSourceLineWriter to allow executable files to be in locations different from the locations of the PDB files.
- Minor style issue:
* #define guards.
* No space before ')' and after '('.
R=mark@chromium.org, wfh@chromium.org
Review URL: https://breakpad.appspot.com/1434002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1309 4c0a9323-5329-0410-9bdc-e9ce6186880e
The ElfCoreDumpTest.ValidCoreFile unit test assumed that the number of
NT_FPREGSET / NT_PRXFPREG notes in the core dump file equals to the number of
threads of the crashed process. This assumption isn't always true as the kernel
skips filling the NT_FPREGSET / NT_PRXFPREG note of a thread if the FPU state
isn't available. The kernel indicates the availability of NT_FPREGSET /
NT_PRXFPREG via the pr_fpvalid field of the NT_PRSTATUS note. This CL modifies
the ElfCoreDumpTest.ValidCoreFile unit test to verify the number of NT_FPREGSET
and NT_PRXFPREG notes based on the pr_fpvalid field of the NT_PRSTATUS notes.
BUG=577
TEST=Run unit tests on x86 and x86_64 Linux platform.
R=vapier@chromium.org
Review URL: https://breakpad.appspot.com/1404002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1303 4c0a9323-5329-0410-9bdc-e9ce6186880e
This is an initial attempt to add Arm64 (aarch64) support to Breakpad for
Linux / Android platforms. This CL adds the Arm64 data structures, but does
not yet implement the Android getcontext support or CPUFillFromThreadInfo /
CPUFillFromUContext.
BUG=354405,335641
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/1354002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1301 4c0a9323-5329-0410-9bdc-e9ce6186880e
The current CreateChildCrash logic is racy when it comes to creating a
crash dump for two reasons:
The main thread that calls kill() on a different thread is guaranteed
the signal will be *queued* when it returns, but not *delivered*. If
the kernel doesn't automatically schedule the receiving thread, but
instead lets the main thread run to the exit() call, then the signal
never triggers a coredump and the whole process simply exits.
The main thread is using kill() to try to deliver a signal to a
specific thread, but that function is for sending signals to a
process. That means the kernel is free to deliver the signal to
any thread in the process and not just the one requested. This
manifests itself as the pr_pid in the coredump not being the one
expected. Instead, we must use tkill() with the tid (which we
already took care of gathering) to deliver to a specific thread.
These are a lot easier to see on a UMP system as contention is heavier.
BUG=chromium:207918
TEST=`dumper_unittest` still passes, and doesn't flake out in a UMP system
TEST=`linux_client_unittest` still passes
R=benchan@chromium.org
Review URL: https://breakpad.appspot.com/1304005
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1299 4c0a9323-5329-0410-9bdc-e9ce6186880e
(instead of C++) it gets upset about the default argument. Instead of
using a default argument I split the function up into two separate
functions.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1280 4c0a9323-5329-0410-9bdc-e9ce6186880e
The Mac crash key manipulation code was intended to be thread-safe through the
provision of a mutex. The mutex operations were done inside an assert().
assert() is a no-op in NDEBUG (release) builds. Therefore, in release builds,
these operations were occurring without being protected by any mutex at all,
and were nowhere near thread-safe.
BUG=chromium:331268
R=rsesek@chromium.org
Review URL: https://breakpad.appspot.com/1034002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1270 4c0a9323-5329-0410-9bdc-e9ce6186880e
