For common signals: SIGILL, SIGFPE, SIGSEGV, and SIGBUS.
Change-Id: I80048f70445c3fa6accd548704c5700b3bed12a4
Reviewed-on: https://chromium-review.googlesource.com/1012589
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Adds an optional 'm' as the first field in FUNCTION and PUBLIC records
to indicate that the address corresponds to more than one symbol.
Controls this by a command line flag for now to give symbol file users
a chance to update.
Also reduces the number of IDiaSymbols retained in memory to one per
address. This reduces memory consumption by 8% when processing
chrome.dll.pdb.
Updates the processor to parse the new optional field.
Bug: google-breakpad:751
Change-Id: I6503edaf057312d21a1d63d9c84e5a4fa019dc46
Reviewed-on: https://chromium-review.googlesource.com/773418
Reviewed-by: Mark Mentovai <mark@chromium.org>
Note that the current MicrodumpProcessor::Process implementation has a
bug due to the fact that it creates a local Microdump instance, and then
holds onto a pointer to the object returned by microdump.GetMemory()
which is destroyed when microdump goes out of scope. This CL fixes the
crash by making Microdump outlive MicrodumpProcessor, which is the same
pattern that Minidump/MinidumpProcessor uses.
Bug: google-breakpad:748
Change-Id: I554b46d309649cf404523722bd9ee39e17a10139
Reviewed-on: https://chromium-review.googlesource.com/720809
Reviewed-by: Primiano Tucci <primiano@chromium.org>
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
The main motivation for this change is to handle very large stack
traces, normally the result of infinite recursion. This part is
actually fairly simple, relaxing a few self-imposed limits on how
many frames we can unwind and the max size for stack memory.
Relaxing these limits requires stricter and more consistent checks for
stack unwinding. There are a number of unwinding invariants that apply
to all the platforms:
1. stack pointer (and frame pointer) must be within the stack memory
(frame pointer, if preset, must point to the right frame too)
2. unwinding must monotonically increase SP
(except for the first frame unwind, this must be a strict increase)
3. Instruction pointer (return address) must point to a valid location
4. stack pointer (and frame pointer) must be appropriately aligned
This change is focused on 2), which is enough to guarantee that the
unwinding doesn't get stuck in an infinite loop.
1) is implicitly validated part of accessing the stack memory
(explicit checks might be nice though).
4) is ABI specific and while it may be valuable in catching suspicious
frames is not in the scope of this change.
3) is also an interesting check but thanks to just-in-time compilation
it's more complex than just calling
StackWalker::InstructionAddressSeemsValid()
and we don't want to drop parts of the callstack due to an overly
conservative check.
Bug: chromium:735989
Change-Id: I9aaba77c7fd028942d77c87d51b5e6f94e136ddd
Reviewed-on: https://chromium-review.googlesource.com/563771
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
The current stack output is one line byte string which is not easy for
humans to parse. Extend the print mode to support a hexdump-like view
and switch to that by default. Now we get something like:
Stack
00000000 20 67 7b 53 94 7f 00 00 01 00 00 00 00 00 00 00 | g{S...........|
00000010 00 70 c4 44 9a 25 00 00 08 65 7a 53 94 7f 00 00 |.p.D.%...ezS...|
BUG=chromium:598947
Change-Id: I868e1cf4faa435a14c5f1c35f94a5db4a49b6a6d
Reviewed-on: https://chromium-review.googlesource.com/404008
Reviewed-by: Mark Mentovai <mark@chromium.org>
The base class here declares Read as virtual, so make sure it's
marked as override in the derived classes. This fixes some build
errors with clang.
src/google_breakpad/processor/minidump.h:853:8: error:
'Read' overrides a member function but is not marked 'override'
[-Werror,-Winconsistent-missing-override]
bool Read(uint32_t expected_size_);
^
src/google_breakpad/processor/minidump.h:153:16: note:
overridden virtual function is here
virtual bool Read(uint32_t expected_size) = 0;
^
Change-Id: Ie4e5fec097b7f37739433a9deb39e7ed60471461
Reviewed-on: https://chromium-review.googlesource.com/444385
Reviewed-by: Tobias Sargeant <tobiasjs@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>
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>
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 .
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>.
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>.
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 .
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/
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 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 .
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
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
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
- 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
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
