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>
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>
For more details take a look at common/using_std_string.h
BUG=
Change-Id: I11f1ce697be23e13f12ea8f0468bbe02fa63c967
Reviewed-on: https://chromium-review.googlesource.com/378159
Reviewed-by: Mark Mentovai <mark@chromium.org>
Some projects will get build break because the comipler is confused when
searches for the standard stdio.h. Rename the wrapper file to avoid that.
renamed: src/common/stdio.h -> src/common/stdio_wrapper.h
modified: src/processor/minidump.cc
modified: src/processor/dump_context.cc
modified: src/processor/logging.cc
modified: src/processor/minidump.cc
modified: src/processor/minidump_processor.cc
modified: src/processor/stackwalk_common.cc
modified: src/processor/symbolic_constants_win.cc
R=mark@chromium.org, labath@google.com
Review URL: https://codereview.chromium.org/1864603002 .
Patch from Yunxiao Ma <yxma@google.com>.
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 .
Older versions of MSVC don't have a snprintf functions. Some files
were already working around that, but not all of them. Instead of
copying the logic into every file, I centralize it into a new
stdio.h wrapper file and make other files include that.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1602563003 .
Patch from Pavel Labath <labath@google.com>.
This feature is enabled only when "-s" is provided as a commandline option.
minidump_stackwalk.cc:
- Add a new commandline option "-s" to output stack contents.
- Instantiate Minidump object in PrintMinidumpProcess() to keep it alive longer so that accessing process_state.thread_memory_regions() in stackwalk_common.cc doesn't result in use-after-free.
stackwalk_common.cc:
- Add a new function PrintStackContents() to output stack contents.
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/9774002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1429 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
This introduces the microdump_stackwalk binary which takes advantage
of the MicrodumpProcessor to symbolize microdumps.
Its operation is identical to the one of minidump_stackwalk.
This CL, in fact, is also refactoring most of the common bits into
stackwalk_common.
BUG=chromium:410294
R=mmandlis@chromium.org
Review URL: https://breakpad.appspot.com/4704002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1405 4c0a9323-5329-0410-9bdc-e9ce6186880e
