At the moment, the Minidump class only supports reading simple and
list annotations from Crashpad minidumps. This change adds support
for reading annotation objects stored in Crashpad modules
(MDRawModuleCrashpadInfo) and exposes them via a new getter in
MinidumpCrashpadInfo.
Change-Id: I033fc4a4fdff5901babc2472e0150f79af56b830
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/4195756
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This uses DisassemblerObjdump to add a processing step in
MinidumpProcessor to compute the true faulting address from register
state and disassembly of the fault instruction when the fault address
is suspicious (-1).
Bug: 901847
Change-Id: Ia1f77d542c4055c82ce2504db8c84a9e52001866
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3932957
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
sed -i '' -E -e 's/Copyright (\(c\) )?([0-9-]+),? (Google|The Chromium Authors).*(\r)?$/Copyright \2 Google LLC\4/' -e '/^((\/\/|#| \*) )?All rights reserved\.?\r?$/d' -e 's/name of Google Inc\. nor the/name of Google LLC nor the/' -e 's/POSSIBILITY OF SUCH DAMAGE$/POSSIBILITY OF SUCH DAMAGE./' $(git grep -El 'Copyright (\(c\) )?([0-9-]+),? (Google|The Chromium Authors).*$')
Plus manual fixes for src/processor/disassembler_x86.{cc,h}.
Plus some conversions from CRLF to LF line endings in .cc and .h files.
Bug: chromium:1098010
Change-Id: I8030e804eecd9f5a1ec9d66ae166efd8418c2a67
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3878302
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Previously these all resulted in EXCEPTION_STACK_BUFFER_OVERRUN
but this hides various specific fast fail crash types, which
are now provided based on the exception's subcode.
Tests: added to minidump_process_unittest.cc
Bug: 865632
Change-Id: Ic6693de247da55cf6d132d108c6e20c635f366b1
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3771437
Reviewed-by: Robert Sesek <rsesek@chromium.org>
for Windows x64 stacks.
According to https://reviews.llvm.org/D2474, LLVM does't generate unwind info for leaf function which doesn't touch any callee-saved
registers. According to MSDN, leaf functions can be unwound simply by
simulating a return.
Change-Id: Ic0503e2aca90b0ba5799133ea8439f1b5f2eefda
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3489332
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This is needed in order to properly detect and highlight frames that
correspond to multiple functions, for example as the result of identical
code folding by the linker.
Bug: google-breakpad:751
Change-Id: I2ee7c147fcff6493c2454383ad5422b38269759a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3471034
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This is similar to the processor part of
https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3232838/,
but added compatibility to process both old and new format of
INLINE/INLINE_ORIGIN records in symbol file.
Old INLINE format:
INLINE <inline_nest_level> <call_site_line> <origin_id>
[<address> <size>]+
New INLINE format:
INLINE <inline_nest_level> <call_site_line> <call_site_file_id>
<origin_id> [<address> <size>]+
Old INLINE_ORIGIN format:
INLINE_ORIGIN <origin_id> <file_id> <name>
New INLINE_ORIGIN format:
INLINE_ORIGIN <origin_id> <name>
Change-Id: I555d9747bfd44a1a95113b9946dcd509b7710876
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3248433
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This reverts commit 54d878abcb.
54d878abcb changed the dump_syms format incompatibly. This must be
redone in a multi-step process: the processor must be made to understand
the old and new formats simultaneously and the processor service must be
rebuilt and run with that update before dump_syms output can change to
use the new format.
Bug: chromium:1263390
Change-Id: I5b6f8aff8ea2916b2c07ac6a74b569fa27db51b9
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3244775
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Processor shows incorrect source file name if a frame have an inlined
frame and their source files are different.
Consider this example:
FILE 0 /tmp/a.h
FILE 1 /tmp/a.cpp
INLINE_ORIGIN 0 0 foo()
FUNC 1110 a 0 main
INLINE 0 22 0 1110 7
1110 7 3 0
1117 3 23 1
When querying the address 0x1110, we know this line 0x1110 corresponds
to /tmp/a.h line 3 and it's inside a inlined function foo() which is
defined at /tmp/a.h and called at line 22. But we don't know at which
file it's being called at line 22. So, we will get stacks like this:
void foo() /tmp/a.h:3
int main() /tmp/a.h:22
The correct stacks should be this:
void foo() /tmp/a.h:3
int main() /tmp/a.cpp:22
In this change:
1. Remove file_id field for INLINE_ORIGIN record.
2. Add call_site_file_id for INLINE record to represents the file where
this call being inlined.
After adding call_site_file_id to it (as third field), it looks like
this:
FILE 0 /tmp/a.h
FILE 1 /tmp/a.cpp
INLINE_ORIGIN 0 foo()
FUNC 1110 a 0 main
INLINE 0 22 1 0 1110 7
1110 7 3 0
1117 3 23 1
Bug: 1190878
Change-Id: Ibbb697d2f7e1b6ac3208cac6fae4353c8743198d
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3232838
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This adds the support to process INLINE and INLINE_ORIGIN records in
symbol files and to generate inlined frames using those records if
possible.
Bug: 1190878
Change-Id: Ia0b6d56c9de37cf818d9bb6842d58c9b68f235b2
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3024690
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Each stackwalker subtracts the size of an instruction
from a frame's instruction pointer to determine which
instruction it was executing. This should also be done
for pointers examined while scanning for likely return
addresses to ensure that those pointers don't point
past the end of functions.
Bug: b/118634446
Change-Id: I043e3f1e51a2c0a3d99ed14bf18ea64dc98add44
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2356649
Reviewed-by: Mark Mentovai <mark@chromium.org>
We do this in a lot of places, but we're inconsistent.
Normalize the code to the Google C++ style guide.
Change-Id: Ic2aceab661ce8f6b993dda21b1cdf5d2198dcbbf
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2262932
Reviewed-by: Sterling Augustine <saugustine@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This code indicates termination under “kill” semantics due to a module’s
code signature becoming invalid.
Bug: chromium:1023239
Change-Id: I3d453af9ef6c6925edcf9c08dbd78e563877522f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1930177
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Now decoding the OS name and exception codes for Fuchsia. Still not decoding exception flags (can be added later, if needed).
Change-Id: If66cb000828be18f0c1b35d1b1f52b3ca3e1fd67
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1699049
Reviewed-by: Mark Mentovai <mark@chromium.org>
ELF modules are loaded in memory in several, possibly discontiguous,
segments. If the holes between segments are large enough, other things,
possibly other ELF modules may be mapped in that space. Crashpad
records the range of modules as the base address of the lowest mapped
segment to the high address of the highest mapped segment. This means
that when one module is mapped into a hole in another, it appears to
the Breakpad processor as overlapping modules. Module ranges are
relevant to the Breakpad processor during stackwalking for identifying
which module a particular program counter belongs to (i.e. mapping the
address to a module's text segment). This patch addresses this issue of
overlapping modules by truncating the range of the module with the
lower base address. A typical module's text segment is the first loaded
segment which would leave the text segment range unaffected. Module
producers can restrict the size of holes in their ELF modules with the
flag "-Wl,-z,max-page-size=4096", preventing other modules from being
mapped in their address range.
Properly contemplating ELF module address ranges would require
extensions to the minidump format to encode any holes.
crbug.com/crashpad/298
This patch also renames the concept of "shrinking down" (which
truncated the upper of two overlapping ranges) to "truncate upper".
Change-Id: I4599201f1e43918db036c390961f8b39e3af1849
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1646932
Reviewed-by: Mark Mentovai <mark@chromium.org>
This struct matches the layout defined by Microsoft and replaces
Breakpad's MDRawContextARM64_Old. This CL updates the processor to
understand either the old or new structs, but clients continue to write
the old structs.
Change-Id: I8dedd9ddb2ec083b802723b9ac87beb18d98edbd
Reviewed-on: https://chromium-review.googlesource.com/1155938
Reviewed-by: Mark Mentovai <mark@chromium.org>
This makes way for the addition of a struct matching Microsoft's layout
for ARM64.
Change-Id: I115f25290863e7438852691d1ec3c9324a42f7a5
Reviewed-on: https://chromium-review.googlesource.com/1152158
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
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>.
