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>
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>
- Ignore DW_TAG_inlined_subroutine with empty range.
- Don't stop parsing after parsing malformed INLINE/INLINE_ORIGIN
records, because reports can still be generated without them but won't
have inlined frames.
Bug: 1190878
Change-Id: I445105ad06b9146268f7d064e85b0d162c3f2a39
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3321166
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This is a more practical reserved capacity than
std::numeric_limits<int>::max() for the vector.
Change-Id: Ic8d4e812c3804e4f15cc51650f7a91bae7313415
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3301419
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Reviewed-by: Lei Zhang <thestig@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>
Building fails for some people because configure requires c++11 but make_unique is a c++14 feature.
Change-Id: I23ce689fc92e9e90a95e7643ff29602f6b32ccbb
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3107784
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>
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>
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>
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 .
Here is the symbol parser output:
E0906 11:27:06.051507 22535 basic_source_line_resolver.cc:76] Line 380187: ParseLine failed
E0906 11:27:06.051614 22535 basic_source_line_resolver.cc:76] Line 380188: ParseLine failed
E0906 11:27:06.051648 22535 basic_source_line_resolver.cc:76] Line 380190: ParseLine failed
E0906 11:27:06.051679 22535 basic_source_line_resolver.cc:76] Line 380191: ParseLine failed
E0906 11:27:06.200814 22535 basic_source_line_resolver.cc:76] Line 446729: ParseLine failed
Here are the contents of the Breakpad symbol file:
FUNC 440d60 49 0 __copy_helper_block_
440d60 b 0 3160 <<<----------- the third number is the line number
440d6b 3e 0 3160 <<<---------------------------- same here
FUNC 440db0 36 0 __destroy_helper_block_
440db0 a 0 3160 <<<---------------------------- same here
440dba 2c 0 3160 <<<---------------------------- same here
Review URL: https://breakpad.appspot.com/629002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1214 4c0a9323-5329-0410-9bdc-e9ce6186880e
More specifically:
- Detect corrupt symbols during minidump processing and provide the list of modules with corrupt symbols in the ProcessState. This will allow listing the corrupt symbol files in the final crash report.
- Skip and recover from symbol data parse errors - don't give up until 100 parse errors are seen.
- In order to recover from '\0' (null terminator) in the middle of a symbol file, a couple of methods have to be updated to require both buffer pointer and length. Previously they required only a buffer pointer (char *) and the size of the buffer was evaluated using strlen which is not reliable when the data is corrupt. Most of the changes are due to these signature updates.
- Added and updated unittests.
Also, updated minidump_stackwalk to show a WARNING for corrupt symbols. Output looks like this:
...
Loaded modules:
0x000da000 - 0x000dafff Google Chrome Canary ??? (main)
0x000e0000 - 0x0417dfff Google Chrome Framework 0.1500.0.3 (WARNING: Corrupt symbols, Google Chrome Framework, 4682A6B4136436C4BFECEB62D498020E0)
0x044a8000 - 0x04571fff IOBluetooth 0.1.0.0
...
Review URL: https://breakpad.appspot.com/613002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1200 4c0a9323-5329-0410-9bdc-e9ce6186880e
Add a CFIFrameInfo class (named for symmetry with WindowsFrameInfo) to
represent the set of STACK CFI rules in effect at a given instruction,
and apply them to a set of register values. Provide a SimpleCFIWalker
class template, to allow the essential CFI code to be shared amongst
the different architectures.
Teach BasicSourceLineResolver to partially parse 'STACK CFI' records,
and produce the set of rules in effect at a given instruction on
demand, by combining the initial rule set and the appropriate rule
deltas in a CFIFrameInfo object.
Adapt StackwalkerX86 and StackFrameX86 to retrieve, store, and apply
CFI stack walking information.
Add validity flags for all the general-purpose registers to
StackFrameX86::ContextValidity.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@549 4c0a9323-5329-0410-9bdc-e9ce6186880e
We've gotten mixed advice from the lawyery types about whether this
matters. But it's easy enough to do.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@517 4c0a9323-5329-0410-9bdc-e9ce6186880e
This looks a little odd right now, since ParseStackInfo has only one
alternative to handle, but I think breaking this out should make the
subsequent addition of STACK CFI record support easier to review.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@514 4c0a9323-5329-0410-9bdc-e9ce6186880e
Rename BasicSourceLineResolver::Module::StackInfoTypes to
WindowsFrameInfoTypes. This enum really describes the forms of
Windows-specific stack unwinding data (STACK WIN records), and its
name should reflect that, especially since we'll be adding support for
other kinds of stack walking information.
The 'stack' -> 'frame' shift matches the naming of the
WindowsFrameInfo type.
Similarly, rename BasicSourceLineResolver::Module::stack_info_ to
windows_frame_info_.
Do similar renamings in basic_source_line_resolver_unittest.cc.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@513 4c0a9323-5329-0410-9bdc-e9ce6186880e
In r480, I botched the change to make the comparisons that decide
whether an address falls within a function's range safe from overflow.
The original code said:
address >= function_base && address < function_base + function_size
which is fine unless the function abuts the end of the address space,
in which case the addition overflows and you get a false negative.
My change subtracted function_size from both sides of the latter
comparison, which is meaning-preserving in true math, and gets you:
address >= function_base && address - function_size < function_base
This not only reads strangely, but also still overflows if
function_size is greater than address. That's rare, but I've added a
case to the unit tests that checks it.
My intent had been to replace the addition which could overflow with a
subtraction that was known not to overflow, namely:
address >= function_base && address - function_base < function_size
This is equivalent to the original in true math, and because of the
first comparison, we know the subtraction won't underflow in MemAddr
math.
The patch includes similar fixes to the public symbol lookup code, and
to FindWindowsFrameInfo, which was the only other function affected by
r480.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@503 4c0a9323-5329-0410-9bdc-e9ce6186880e
At the moment, FillSourceLineInfo returns Windows DIA-based stack
walking data. In addition to being ugly, this makes it difficult to
provide access to DWARF CFI-based stack walking data in a symmetrical
way.
This patch changes FillSourceLineInfo to do the single job its name
suggests, and adds a second member function to
SourceLineResolverInterface to retrieve Windows DIA stack walking
information. A sibling member function will provide access to DWARF
CFI stack walking data.
a=jimblandy, r=mmentovai
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@480 4c0a9323-5329-0410-9bdc-e9ce6186880e
Also, rename stack_frame_info.h to windows_frame_info.h.
If it seems odd to have functions like FillSourceLineInfo returning
Windows-specific data structures... well, it is! This patch just makes
it more obvious what's going on.
a=jimblandy, r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@471 4c0a9323-5329-0410-9bdc-e9ce6186880e
Modern GNU compilers warn about the #inclusion of <ext/hash_map>; that
container is deprecated, and code should use <tr1/unordered_map>
instead. However, to stay within the boundaries of C++ '98, it's
probably fine just to use plain old std::map.
Breakpad uses hash_map in three cases:
o The DWARF reader's SectionMap type maps object file section names to
data. This map is consulted once per section kind per DWARF
compilation unit; it is not performance-critical.
o The Mac dump_syms tool uses it to map machine architectures to
section maps in Universal binaries. It's hard to imagine there
ever being more than two entries in such a map.
o The processor's BasicSourceLineResolver uses a hash_map to map file
numbers to file names. This is the map that will probably have the
most entries, but it's only accessed once per frame, after we've
found the frame's line entry.
a=jimblandy
r=nealsid
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@393 4c0a9323-5329-0410-9bdc-e9ce6186880e
