aboutsummaryrefslogtreecommitdiff
path: root/src/processor/fast_source_line_resolver.cc
AgeCommit message (Collapse)Author
2022-09-07Update copyright boilerplate, 2022 edition (Breakpad)Mark Mentovai
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>
2022-02-19Populating is_multiple in google_breakpad::StackFrame from symbol files.Ivan Penkov
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>
2021-12-09Fixing issues in the Breakpad symbol file serialization code.Ivan Penkov
- FastSourceLineResolver::Module::LoadMapFromMemory now rejects an older version of the serialization format. - Cleaned up several unneeded usages of scoped_ptr::get. - Fixed the serialization of bool. The serialization code was using 255 for 'true' while the deserialization code was expecting to see 1. - Serialization for PublicSymbol.is_multiple was missing. Deserialization was expecting it - Added some logging to processor/source_line_resolver_base.cc Change-Id: Iadc7d8ee23bf3a07e4ea280d5d4c3f25f6278b69 Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3324395 Reviewed-by: Joshua Peraza <jperaza@chromium.org>
2021-12-01Add serialization of inlines and inline origins for FastSourceLineResolver ↵Zequan Wu
so that it can construct inlined frames later. Bug: 1190878 Change-Id: Ie3b0f2f44e04e790501ea54680fe223974c750ab Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/3294126 Reviewed-by: Joshua Peraza <jperaza@chromium.org>
2021-10-29Make processor compatible with both old and new format INLINE/INLINE_ORIGINZequan Wu
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>
2021-10-26Revert "Fix incorrect source file name for inlined frames"Mark Mentovai
This reverts commit 54d878abcb61623a71e5c2b5bb251e7f7fc8563d. 54d878abcb61 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>
2021-10-20Fix incorrect source file name for inlined framesZequan Wu
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>
2021-07-22Add support to process INLINE records in symbol filesZequan Wu
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>
2020-07-15fix pointer style to match the style guideMike Frysinger
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>
2013-07-11Detect corrupt symbol files during minidump processing. Recover from the ↵ivan.penkov@gmail.com
errors and use the good data if possible. 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
2013-03-06Use stdint types everywhereted.mielczarek@gmail.com
R=mark at https://breakpad.appspot.com/535002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1121 4c0a9323-5329-0410-9bdc-e9ce6186880e
2013-01-17Move scoped_ptr.h to commonted.mielczarek@gmail.com
R=mark at https://breakpad.appspot.com/509002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1096 4c0a9323-5329-0410-9bdc-e9ce6186880e
2012-06-28This change allows compiling the google-breakpad code using a global ↵ivan.penkov@gmail.com
::string class instead of std::string. For more details take a look at common/using_std_string.h git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@974 4c0a9323-5329-0410-9bdc-e9ce6186880e
2012-06-12This is a fix for a stackwalker_x86 issue which has toivan.penkov@gmail.com
do with FPO (frame-pointer-omission) optimized context frames where the context frame represents a Windows System call stub. git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@971 4c0a9323-5329-0410-9bdc-e9ce6186880e
2010-11-01Restrict ownership of symbol data buffers to symbol supplier.SiyangXie@gmail.com
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@721 4c0a9323-5329-0410-9bdc-e9ce6186880e
2010-10-21FastSourceLineResolver implementation for optimization purpose.SiyangXie@gmail.com
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@719 4c0a9323-5329-0410-9bdc-e9ce6186880e
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-27 06:17:05 +0000