| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
| |
Adding remaining mips n64 support including stackwalker.
BUG=None
TEST=manually tested on Linux/Android
R=vapier@chromium.org
Review URL: https://codereview.chromium.org/1418453011 .
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to figure out what symbols we need associated to a minidump,
it is useful to be able to dump all the modules the minidump contains.
A=dyen@chromium.org
Original Review: https://codereview.chromium.org/1651593002/
BUG=563716
R=dyen@chromium.org
Review URL: https://codereview.chromium.org/1650713002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In C/C++, the result of signed integer overflow is undefined.
The expression "base + size - 1" is parsed as "(base + size) - 1", and
"base + size" can overflow even if "base + (size - 1)" <= INT_MAX.
See http://g/c-compiler-chrome/461JohPKakE/JI3rEBg6FwAJ for more.
BUG=None
TEST='CC=clang CXX=clang++ ./configure && make check'
R=vapier@chromium.org
Review URL: https://codereview.chromium.org/1591793002 .
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>.
|
|
|
|
|
|
|
|
|
| |
A=thakis@chromium.org
Original Review: https://codereview.chromium.org/1550933002/
R=thakis@chromium.org
Review URL: https://codereview.chromium.org/1554613002 .
|
|
|
|
|
|
|
|
|
| |
file ends with 0
R=ivanpe@chromium.org
BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=668
Review URL: https://codereview.chromium.org/1482363003 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
than 2013.
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=669
R=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 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
R=ivanpe at https://codereview.chromium.org/1292503005/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1496 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
|
| |
crrev.com/1298443002 has introduced a build failure by re-defining
__STDC_FORMAT_MACROS. Fixing it.
BUG=
R=mark@chromium.org, ted.mielczarek@gmail.com
Review URL: https://codereview.chromium.org/1303493003 .
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1493 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
| |
R=ivanpe at https://codereview.chromium.org/1298443002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1491 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
|
| |
This CL also consequentially adds a public method to get the number of
mappings in a Linux minidump.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1291603002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1488 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
| |
mappings when rating Linux exploitability.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1286033002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1487 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
| |
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1288323003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1486 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
| |
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1485 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
| |
R=lei at https://codereview.chromium.org/1211963002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1484 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
| |
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1280853003
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1483 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
|
|
|
|
|
|
|
| |
MinidumpLinuxMapsList.
R=ivanpe@chromium.org
Review URL: https://codereview.chromium.org/1287803002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1482 4c0a9323-5329-0410-9bdc-e9ce6186880e
|