The auto-detection of the UUID was missing the extra "0" added for
compatibility reasons. The native upload also was sending malformed
HTTP.
Change-Id: I8c261fc525f0f0086f269f2dee02941dd55488cb
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2739320
Reviewed-by: Nelson Billing <nbilling@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
There's no need to pass in debug ID to symupload for native symbol
uploads, as breakpad can extra the ID itself for dsym and macho types.
Change-Id: Ib0b7703eac85bc84fe1f095e678d75b347bd872a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2724731
Reviewed-by: Nelson Billing <nbilling@google.com>
Reviewed-by: Mark Mentovai <mark@chromium.org>
For a crash at the function entry with corrupted PC, the caller's PC
could be lying in the link register. Using the PC from link register
would be more effective than blindly scanning the stack immediately.
Change-Id: I51673b7298e70faeeab2bfa97075e3c4793f94bc
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2678992
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When built with -Werror, dwar2reader.cc fails to build with three
-Wunused-variable warnings. This CL fixes that.
Change-Id: I10487644377d623d850acc258a94bbacb368ffae
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2638927
Reviewed-by: Sterling Augustine <saugustine@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Fifth of 5 small patches to fix various breakpad issues found
while testing dump_syms of DWARF v5 in ChromeOS.
DWARF v5 introduces a new dwp version, version 5. The current
dwp reader only recognizes versions 1 & 2 as valid dwp versions. This
CL fixes that.
Change-Id: I5ac43b318b59e406ca1f6749232709aaef59a67b
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2634550
Reviewed-by: Sterling Augustine <saugustine@google.com>
Fourth of 5 small patches to fix various breakpad issues found
while testing dump_syms on DWARF v5 in ChromeOS.
Dwarfv5 adds many new Type Unit sections to debug information. Since
these only contain type information, they are of no interest to
dump_syms. This CL gets dump_syms to skip trying to process the
type unit sections. Without this CL, dump_syms takes ~ 3 hours to
process the DWARF v5 Chrome binary. With this CL, dump_syms takes
~ 8 minutes to process the DWARF v5 Chrome binary (about the same
time as it takes for DWARF v4).
This CL also adds a test case to verify that type units are being
skipped.
Change-Id: Ie0bb2d675718f7041b8e9b3186ed44f80a3ad39c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2634549
Reviewed-by: Sterling Augustine <saugustine@google.com>
Third of 5 small patches to fix various breakpad issues found
while testing dump_syms on DWARF v5 in ChromeOS.
The offset into the line table was being incorrectly added to the
.debug_string and debug_line_str sections in the code for reading
the line table. It was also skipping trying to read the line table
if the .debug_line_str section was present. This CL fixes these
issues.
Change-Id: If14543731016bcee201b8c33dca53e9520007222
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2634548
Reviewed-by: Sterling Augustine <saugustine@google.com>
Second of 5 small patches to fix various breakpad issues found
while testing dump_syms on DWARF v5 in ChromeOS.
This patch adds code to properly find & parse the
DW_AT_str_offsets_base attribute, and use it to handle strings
of the forms DW_FORM_strx, DW_FORM_strx1..DW_FORM_strx4 This is the
largest of the DWARF5 fixes. It also includes a unittest to test
using a string offset.
Change-Id: I5d1def862d9d91cae4b2853578441e04ea85449d
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2634547
Reviewed-by: Sterling Augustine <saugustine@google.com>
First of 5 small patches to fix various breakpad issues found
while testing dump_syms on DWARF v5 in ChromeOS.
This patch adds some missing DWARF enums, and their uses, and fixes
one small typo (was updating 'lineptr' instead of '*lineptr').
Change-Id: Ic674d5db29f29a69a3f6e370d0553eb4139c91de
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2634546
Reviewed-by: Sterling Augustine <saugustine@google.com>
With optimizations such as -fsplit-machine-functions (clang) and
-freorder-blocks-and-partition (gcc), the function body may be
discontiguous in the binary. Control flow between the parts are routed
using jumps. This test ensures that breakpad consumes debuginfo
generated by the -fsplit-machine-functions optimization and the line
table for the cold function part is correct.
Change-Id: I44d59704864ee940dd429c5249d5d793fe081d6a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2591951
Reviewed-by: Sterling Augustine <saugustine@google.com>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When initializing the LineReader, the size passed should be the sizeof
the dwarf4 line program.
Change-Id: I67e6fa404d4fa8851e4958013a35a061fe169156
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2585345
Reviewed-by: Sterling Augustine <saugustine@google.com>
On Linux, this tool generates a minidump for given process. It requires
the permission to trace the process and access its /proc directory. This
is useful when a defective behavior of a process does not lead to a
crash. For example, it can be used by a watchdog or if a process does
not correctly respond to a termination request.
Change-Id: Iab501e42c064a537aea62831c471e395ff697186
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2539920
Reviewed-by: Mike Frysinger <vapier@chromium.org>
On Linux, it is possible to register a core handler via
/proc/sys/kernel/core_pattern. Doing so invokes the core handler when
a process crash. The core_handler uses /proc/<pid>/mem to access the
process memory. This way it is not necessary to process the full
coredump which takes time and consumes memory.
In order to profit from this core handler, for example, one can
integrate dump_syms into Yocto and generate an archive with the
breakpad symbols of all the binaries in the rootfs. Minidumps are
especially useful on embedded systems since they are lightweight and
provide contextual information.
Change-Id: I9298d81159029cefb81c915831db54884310ad05
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2536917
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Bug: Test Dwarf5ReadRangeList does not compile with GCC 10 because of
Change-Id: Ibeea82084bbf4c1d0e760a7bba14109401cf3639
duplicated declaration.
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2536913
Reviewed-by: Sterling Augustine <saugustine@google.com>
Most of this is simple, "Read the form, get the data, then
call ProcessAttribute."
Handling DW_FORM_implcit_const is a little trickier, as it
is the only form that stores its value inline in the abbrev
table itself. Add a test for that.
Print errors for supplementary object files.
Change-Id: I0999b039848bded1891998a866e5059acd538a09
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2446627
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
This is a big change. dwarf5 range lists are quite a bit more complicated
than dwarf 4 range lists, both in the contextual information required, and
in their own representation and interpretation.
The big design choice here is how to pass the CU information all the
way down to the reader. I chose a structure, because otherwise the
parameter list gets very long and error prone (and has to be passed
down several levels). This structure could be made a parto of the CU
context itself, or the range handler, so it wouldn't have to be
separately assembled at range-list read time, but both of those
solutions get even more invasive, and harder to follow.
I've tried to figure out how to break this into smaller changes, but it
affects nearly everything that has to do with a compilation unit's
own addresses and when decisions must be made about how to read them.
Dependency injection will do that to you.
It does add tests for range list reading, which did not exist before.
Change-Id: I923b9a2c3379a0f52609bc05310097de5cbb7227
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2446635
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
CFI might compute invalid rsp/rip values if the values in the callee
frame were corrupted, as in stack overflow. Rejecting the frame
computed by CFI allows Breakpad to fall-back to scanning.
Bug: b/169611285
Change-Id: Ifeb08ab5639932c0e23722a161d9d15403738019
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2456037
Reviewed-by: Mark Mentovai <mark@chromium.org>
This reverts commit 2b936b06c1.
After getting deep into the dwarf5 range reader, I realized that this
should be done a somewhat different way. So reverting in favor or
a better design, coming in a few minutes.
Change-Id: Ie0b2846e70b3df1e637831e96ea69fe093f4e712
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2446011
Reviewed-by: Mark Mentovai <mark@chromium.org>
Dwarf5 introduces a new .debug_rngslist section, to take the place
of the Dwarf4 .debug_ranges. However, the dwarf version is CU-based,
and not file-based, so there can be both sections, and which section
the CU needs isn't known until the dwarf parser encounters either
DW_AT_ranges (dwarf 4 and lower) or DW_AT_rnglists_base (dwarf 5).
This change refactors the code around range lists and range list
readers to defer the decision of what section to parse until
the relevant attribute is found. It moves the range list section
reader from the range-list handler itself (which doesn't know which
section it will use) to the CU context, and then lets the handler
know when it encounters DW_AT_ranges.
I will add a reader for the new dwarf5 section, along with the code to
interpret the new section, and its forms and such in a subsequent patch.
Change-Id: Ie92e4c9daa3f0acb98d7ef74f6b9c2065db849b1
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2433684
Reviewed-by: Mark Mentovai <mark@chromium.org>
- Mac OS symupload used to check for errors in JSON serialization by
inspecting the "error" out parameter of the serialization function. Now
it checks the returned data for "nil".
- Similar change for the HTTP request that's made in the same function.
Change-Id: I86f50ef44e60ee119c302e0614b115a8d35e9b5b
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2390753
Reviewed-by: Mark Mentovai <mark@chromium.org>
We have API's for copying files & changing file modes, so there's
no sense in using system() to run programs to do that.
For the strip call, do the minimal spawn+wait dance. This avoids
weird quoting string issues at least.
Change-Id: Ibda117f243e886c0c7fcf8076fb8602b8d3ba42d
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2396558
Reviewed-by: Mark Mentovai <mark@chromium.org>
Breakpad should only map the file content after the offset instead of
the whole file. Mapping the whole file while only unmap 'file_len - offset'
would leak 'offset' bytes of mapping in virtual memory.
Change-Id: I10be4f929d969703a6a02c1f709d2a4ca86a6e9e
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2393468
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Some vendor library doesn't contain the section header. It causes
segmentation fault in `FindElfClassSection`.
> e_shoff:
> This member holds the section header table's file offset in bytes.
> If the file has no section header table this member holds zero.
Change-Id: Id98d6ff3bd16af4541deb5a55a8fad2fa74eda23
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2354427
Reviewed-by: Mark Mentovai <mark@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>
- Attempt to escape all characters which must be escaped in a URL or JSON string, for debug_file, since almost all of these are legal filename characters.
Change-Id: Ic7a9c1aef00093d164683be7db84f4f282f45f7a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2339706
Reviewed-by: Mark Mentovai <mark@chromium.org>
- This change should also be made for other platforms.
- This allows users to tell the difference between upload succeeding, failing, and being skipped because the file already exists on server.
Change-Id: I0b404da7aac29e0a16346bbd816ad1c815985bce
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2341373
Reviewed-by: Mark Mentovai <mark@chromium.org>
- Checking symbol status would fail for files whose names contained spaces, because the file name was being put in the URL unescaped.
- Now the filename is escaped before being put in URL when checking symbol status.
Change-Id: I3b989d877e0fd9aef57ec13bdbbb6c3dacb6a9e2
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2339782
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
These fields are only used when NDEBUG is not defined. We get build
failures with the current code like:
src/common/dwarf/dwarf2reader.h:181:12: error: private field 'string_buffer_length_' is not used [-Werror,-Wunused-private-field]
uint64_t string_buffer_length_;
Change-Id: I01d6e29d31d50e29ed3736e7197e70455724ae48
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2299022
Reviewed-by: Sterling Augustine <saugustine@google.com>
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 the upcoming Dwarf5 LineInfo changes, we will need to get
several additional sections by name, but without a the Compilation
Unit. This change prepares for that.
Change-Id: I566855abb339a856110a2f7d243d3848fe2b3c18
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2268861
Reviewed-by: Mark Mentovai <mark@chromium.org>
Given the almost nonexistent direct dwarfreader tests, I think
the best way to test these dwarf5 additions will be to add a full
dwarf5 compilation unit similar to the ones used incidentally in
the other tests. But I can't do that until enough dwarf5 is
correctly implemented.
Change-Id: I3418bda7212ae85c4b67232a2ab8fea9b9ca5d42
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2258838
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Adding the new forms by type and processing should avoid
the problems with 0c0e24f709,
where new forms weren't handled in switch statements, breaking
the build.
Testing this should follow the testing for DW_FORM_GNU_str_index,
very closely, but there doesn't appear to be any tests for that,
or even DW_FORM_strp.
Change-Id: I609d56b1dc879971bfef1070f063f8457fec6017
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2233839
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: Mark Mentovai <mark@chromium.org>
This should address the issue where some Chrome builds were failing to
upload symbols due to a bad command-line flag, but there was no
indication of a problem, and no build failure, because symupload was
exiting with a success code.
BUG=1091387
R=nbilling@google.com, wuwang@google.com
Change-Id: I0d7f1a6d689ca5fd37be3abad4c5ebc97f108e50
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2231574
Reviewed-by: Nelson Billing <nbilling@google.com>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Bogus demangler warnings should be suppressed on both Mac and Linux
platforms, so there is no reason to keep this filter behind __APPLE__ gate.
Bug: chromium:1062556
Change-Id: Idf28db0b527c3cd6dd91510fcf7d9040aaa64694
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2210684
Reviewed-by: Mark Mentovai <mark@chromium.org>
On Mac a C++ symbol has 1-4 underscore characters followed by a 'Z'.
Symbols that do not have this format (such as plain C symbols)
causes a lot of warnings to be printed.
Bug: chromium:1062556
Change-Id: I55977f756c7e20cc5e7b1cb8e38316d7bf1f748c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2179482
Reviewed-by: Mark Mentovai <mark@chromium.org>
