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>
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>
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
