| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
| |
The sys_mmap/sys_mmap2 weirdness has been cleaned up in lss now and there
is only one API now for everyone -- sys_mmap.
R=mseaborn@chromium.org
Review URL: https://codereview.chromium.org/2065493006 .
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
| |
R=ted
|
|
|
|
|
|
|
| |
These locations have changed since the move from Google Code.
R=ted.mielczarek@gmail.com
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1275630
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__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 .
|
|
|
|
|
|
|
|
| |
BUG=599327
R=primiano@chromium.org
TBR=mark@chromium.org
Review URL: https://codereview.chromium.org/2042873003 .
|
|
|
|
|
|
|
|
| |
BUG=599327
R=primiano@chromium.org
TBR=mark@chromium.org
Review URL: https://codereview.chromium.org/2035343002 .
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
| |
BUG=599327
R=mark@chromium.org, primiano@chromium.org
Review URL: https://codereview.chromium.org/2025923003 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
| |
This breaks building for targets that don't include zlib.
BUG=chromium:604440
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/2010803003 .
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
|
|
|
|
|
|
| |
BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=699
R=mark@chromium.org, primiano@chromium.org
Review URL: https://codereview.chromium.org/2006333002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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=695
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1959643004 .
Patch from Lars Volker <lv@cloudera.com>.
|
|
|
|
|
|
|
| |
BUG=525938
R=mark@chromium.org
Review URL: https://codereview.chromium.org/2008553002 .
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MAC does not have elf.h, so use the elf.h inside the package instead
of the one in the system.
One failure example is
https://codereview.chromium.org/1978803003/
TEST=make; make check
BUG=
R=michaelbai@chromium.org
Review URL: https://codereview.chromium.org/1984713002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is no right fix, we shouldn't allow module overlap.
This reverts commit 4f417c8c0ffceb6c2516c6ef00cd91ca5746d852.
BUG=606972
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1976683004 .
Patch from Tao Bai <michaelbai@chromium.org>.
|
|
|
|
|
|
|
|
|
| |
Updated dump_syms xcode project and ran tests.
BUG=
R=vapier@chromium.org
Review URL: https://codereview.chromium.org/1973113002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds elf.h header from glibc.
Updates dwarf2reader.cc so it isn't comparing a unique_ptr against NULL.
Moves from MacOS10.5 SDK to latest SDK for Xcode project.
Moves from using gcc to clang for dump_syms tests.
Disables warning about 'Missing Field In Structure Initializers' to temporarily work around https://bugs.chromium.org/p/google-breakpad/issues/detail?id=697.
With this patch all tests form dump_syms pass again using Xcode 7.3 on Mac OS X 10.11.
BUG= https://bugs.chromium.org/p/google-breakpad/issues/detail?id=696, https://bugs.chromium.org/p/google-breakpad/issues/detail?id=697
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1970903002 .
|
|
|
|
|
|
|
|
|
|
| |
dsym files generated by Xcode for swift (Xcode 7.3) end with a header, and the
code did not handle that case.
BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=689
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1971793002 .
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the unittest error caused by
https://codereview.chromium.org/1884283002/
TEST=unittest passes on falco board in ChromeOS.
BUG=
R=vapier@chromium.org
Review URL: https://codereview.chromium.org/1952083002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
| |
The %ld expects a long signed integer, but we're passing in a size_t.
Use %zu which is an unsigned size_t type.
R=ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/1951603002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crrev.com/1887033002 introuced a clang warning (see below).
This fixes it, so that breakpad can be rolled in chrome, where
warnings are always fatal.
From: https://build.chromium.org/p/tryserver.chromium.android/builders/android_chromium_gn_compile_dbg/builds/59031/steps/compile%20%28with%20patch%29/logs/stdio
FAILED: clang_x64/obj/breakpad/dump_syms/dwarf_cu_to_module.o
../../breakpad/src/common/dwarf_cu_to_module.cc:420:20: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
if (declaration_ && qualified_name || (unqualified_name && enclosing_name)) {
~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~ ~~
../../breakpad/src/common/dwarf_cu_to_module.cc:420:20: note: place parentheses around the '&&' expression to silence this warning
if (declaration_ && qualified_name || (unqualified_name && enclosing_name)) {
^
( )
R=mark@chromium.org, petrcermak@chromium.org
Review URL: https://codereview.chromium.org/1928363002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(https://breakpad.appspot.com/7714003)
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 .
|
|
|
|
|
|
|
|
|
| |
Removes some archaic Google Toolbox For Mac features.
BUG=
R=ivanpe@chromium.org, mark@chromium.org
Review URL: https://codereview.chromium.org/1912473002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
| |
BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=694
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1883253002 .
|
|
|
|
|
|
| |
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1882833004 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depending on compiler's setting, the unreferenced local variable may
cause build break.
modified: src/processor/minidump.cc
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1866533002 .
Patch from Yunxiao Ma <yxma@google.com>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/
|
|
|
|
|
|
| |
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1849933002 .
|
|
|
|
|
|
|
|
|
|
|
|
| |
to code calling libcurl. This change may be used to build a tool to dump and
upload symbols with multi-thread.
BUG=
R=mmandlis@chromium.org
CC=google-breakpad-dev@googlegroups.com
Review URL: https://codereview.chromium.org/1842113002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently EXC_BAD_ACCESS doesn't support EXC_I386_GPFLT as
exception_flags for pretty-printing in the processor, but this happens
for a lot of things:
http://opensource.apple.com/source/xnu/xnu-2050.24.15/osfmk/i386/trap.c
(search for EXC_I386_GPFLT).
And we get a lot of these in the wild:
https://crash-stats.mozilla.com/search/?reason=%3DEXC_BAD_ACCESS+%2F+0x0000000d&cpu_name=amd64&_facets=signature&_facets=address&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=address#crash-reports
This patch makes them show up with a nice name instead of the current
"EXC_BAD_ACCESS / 0x0000000d".
Additionally, this patch fixes some other cases where x86-64 wasn't being handled in the same way as x86, and fixes some x86-specific exception flags to be stringified with I386 in the output.
R=mark@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1833123002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
behavior under sized-delete.
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 .
|
|
|
|
|
|
|
| |
omap.cc(212): warning C4473: 'fprintf' : not enough arguments passed for format string
BUG=None
Review URL: https://codereview.chromium.org/1776613004
|
|
|
|
|
|
|
| |
BUG=585534
R=primiano@chromium.org
Review URL: https://codereview.chromium.org/1750033002 .
|