| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
BUG=
Change-Id: Ib9b0fd5ba7f829f8be8cf856ab371c6540279ee5
Reviewed-on: https://chromium-review.googlesource.com/458526
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current ARM minidump_dump output makes people remember or look up
how registers are mapped in the ISA. Let's use human friendly names
instead so they don't have to.
Currently it looks like:
MDRawContextARM
context_flags = 0x40000006
iregs[ 0] = 0x3c48b000
iregs[ 1] = 0x3
iregs[ 2] = 0x20
iregs[ 3] = 0x0
iregs[ 4] = 0x1c
iregs[ 5] = 0x3c48b000
iregs[ 6] = 0x20
iregs[ 7] = 0x3c48b04c
iregs[ 8] = 0x39100611
iregs[ 9] = 0x1c
iregs[10] = 0x0
iregs[11] = 0xbe61c200
iregs[12] = 0xfb9c1fec
iregs[13] = 0xbe61bd28
iregs[14] = 0x39e19b1c
iregs[15] = 0x357dd74c
cpsr = 0x680b0010
float_save.fpscr = 0x0
Now it looks like:
MDRawContextARM
context_flags = 0x40000006
r0 = 0x3c48b000
r1 = 0x3
r2 = 0x20
r3 = 0x0
r4 = 0x1c
r5 = 0x3c48b000
r6 = 0x20
r7 = 0x3c48b04c
r8 = 0x39100611
r9 = 0x1c
r10 = 0x0
r11 = 0xbe61c200
r12 = 0xfb9c1fec
sp = 0xbe61bd28
lr = 0x39e19b1c
pc = 0x357dd74c
cpsr = 0x680b0010
float_save.fpscr = 0x0
BUG=chromium:665083
Change-Id: I46d87c4ff7303a7efcd60da1d0b67ae7a5465c8f
Reviewed-on: https://chromium-review.googlesource.com/457197
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
|
|
|
|
|
|
|
|
|
| |
Currently on MIPS we accidentally terminate stackwalk if $sp value doesn't change between frames
which results in incomplete callchain terminated at the point of first tailcall encountered.
Change-Id: I8f1ed1df958d8f0a9eb11fd7800062184d8f1ee2
Reviewed-on: https://chromium-review.googlesource.com/449755
Reviewed-by: Mark Mentovai <mark@chromium.org>
|
|
|
|
|
|
|
|
| |
BUG=chromium:661037
Change-Id: Ia4da0bd9787c232a6a199cfdfccfbed60c2515c2
Reviewed-on: https://chromium-review.googlesource.com/450090
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These compile errors occur when building the check target with:
CXX=clang++-3.8
CXXFLAGS="-Werror -Wconstant-conversion -g -O2 -std=c++11"
src/processor/stackwalker_mips.cc:60:9: error: comparison of constant
18446744073709551615 with expression of type 'bool' is always false
[Werror,-Wtautological-constant-out-of-range-compare]
> 0xffffffffffffffff) {
^ ~~~~~~~~~~~~~~~~~~
src/processor/stackwalker_mips.cc:68:66: error: comparison of constant
4294967295 with expression of type 'bool' is always false
[-Werror,-Wtautological-constant-out-of-range-compare]
if ((memory_ && memory_->GetBase() + memory_->GetSize() - 1) > 0xffffffff) {
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~
Change-Id: I29eed8f4a67b9feeb274aa1fc6c79a019135e8d6
Reviewed-on: https://chromium-review.googlesource.com/438445
Reviewed-by: Mike Frysinger <vapier@chromium.org>
|
|
|
|
|
|
| |
Change-Id: Idf3fe363c76734caa3e6a6cc20a53fd1d661188d
Reviewed-on: https://chromium-review.googlesource.com/438564
Reviewed-by: Mark Mentovai <mark@chromium.org>
|
|
|
|
|
|
|
|
| |
BUG=
Change-Id: I6d03820082f793a2eac3c3c2abd184b4acf66aa4
Reviewed-on: https://chromium-review.googlesource.com/438755
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
|
|
|
|
| |
This reverts commit 5c521532fc0a1b65f42c0d61d2da206eadf318b8.
|
| |
|
|
|
|
|
|
|
|
| |
BUG=
Change-Id: I6c1d78cfe344c7b90a03f6df35193d67623bfd89
Reviewed-on: https://chromium-review.googlesource.com/434094
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL hits lots of source files because:
1. An update to the CodeModule virtual class. I added an is_loaded
method to specify whether the module is loaded. There were several
mocks/test classes that needed to be updated with an implementation.
An alternative to this route would be to modify
MinidumpUnloadedModule::code_file to prepend "Unloaded_" to the
module name.
2. Added an unloaded_modules parameter to
StackFrameSymbolizer::FillSourceLineInfo.
BUG=
Change-Id: Ic9c7f7c7b7e932a154a5d4ccf292c1527d8da09f
Reviewed-on: https://chromium-review.googlesource.com/430241
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
BUG=
Change-Id: I19a1abf1d00f208943db1c362cc426ca8bd2068e
Reviewed-on: https://chromium-review.googlesource.com/409632
Reviewed-by: Mark Mentovai <mark@chromium.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of std::string.
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>
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
::string class instead of std::string.
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
| |
The routines used to read from the structure were also modified to accomodate for unknown future versions by skipping over the unsupported part instead of failing.
R=ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/2109063004/ .
|
|
|
|
|
|
|
|
|
| |
See also https://codereview.chromium.org/2130293003/ for Chromium-side change and go/internal_cl_for_2130293003 for internal change.
BUG=chromium:614440
R=mark@chromium.org
Review URL: https://codereview.chromium.org/2160373002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
| |
BUG=587536
R=primiano@chromium.org
Review URL: https://codereview.chromium.org/1704243002 .
|
| |
|
|
|
|
|
|
|
| |
BUG=https://code.google.com/p/chromium/issues/detail?id=584174
R=mmandlis@chromium.org
Review URL: https://codereview.chromium.org/1697963002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GPU infromation in the following format:
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 reverts commit cb936a0243c97ae9cd2d4bb19d95dde0421fed6d.
A=dyen@chromium.org
Original Review: https://codereview.chromium.org/1672773002/
R=dyen@chromium.org
Review URL: https://codereview.chromium.org/1688493003 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|