- 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>
These are left over from when this file was written in C.
In C++, true and false are keywords, so this is no longer necessary.
In fact, redefining a keyword is not actually permitted in ISO C++
(https://eel.is/c++draft/macro.names#2), and is rejected by MSVC.
Change-Id: I2f4a6eae7f8dd4d91b8ee6588c7ae5e8f20bd0d0
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2105831
Reviewed-by: Mike Frysinger <vapier@chromium.org>
__WORDSIZE is an internal libc definition. Instead, we can use
ULONG_MAX from limits.h, whose value corresponds to the machine's
native word size.
This allows us to remove the fallback definition of __WORDSIZE in
the Android compatibility headers.
Bug: google-breakpad:631
Change-Id: I7b9e6f3b2121f78ccad9e32bf26acac518aefd8f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2107100
Reviewed-by: Mike Frysinger <vapier@chromium.org>
getcontext is also not available on musl libc, so generalize
breakpad_getcontext so it can be used as a fallback for non-Android
platforms as well.
On x86_64 and i386, ucontext_t uses an Android-specific offset for
storage of FP registers, since its sigset_t differs in size. So,
make the definition of MCONTEXT_FPREGS_MEM and UCONTEXT_FPREGS_MEM_OFFSET
conditional on whether we are building for Android.
On glibc and musl, signal.h and asm/sigcontext.h can't be included
together, so in breakpad_context_unittest.cc, only compare the libc
and kernel _fpstate when on Android.
Bug: google-breakpad:631
Change-Id: If81d73c4101bae946e9a3655b8d1c40a34ab6c38
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2102135
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The crash address from the microdump was never checked against
anything. Instead, the test was checking the value of a constant.
On 32-bit systems, an intptr_t cannot represent kCrashAddress
(0xDEADDEAD), causing a failure when the crash address is parsed
from the microdump. Instead, use uintptr_t, which matches the type
of kCrashAddress.
Change-Id: Ib5612743803609f7801dcfb98deaa8779e362025
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2100816
Reviewed-by: Mike Frysinger <vapier@chromium.org>
The _libc_fpstate struct tag is an implementation detail of glibc,
and musl uses a different struct tag, _fpstate.
Unfortunately, the public type fpregset_t is a pointer type, so is
not suitable for allocating storage, or referring to constant
storage. Instead, we can use std::remove_pointer<fpregset_t>::type
to refer to the pointed-to type, regardless of the struct tag.
Bug: google-breakpad:631
Change-Id: Iaf47f15b2d834dd8de839431f65a481e9b0c7f9e
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2096171
Reviewed-by: Mike Frysinger <vapier@chromium.org>
__WORDSIZE is an internal libc definition. Instead, we can use
ULONG_MAX from limits.h, whose value corresponds to the machine's
native word size.
Bug: google-breakpad:631
Change-Id: If69caf578286d678585d1510c01562b969b5061f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2097352
Reviewed-by: Mike Frysinger <vapier@chromium.org>
sys/poll.h and sys/signal.h just redirect to the standardized
location for these headers, poll.h and signal.h.
On musl libc, including the incorrect header path results in a
warning, and since breakpad is built with -Werror, this is an error.
In exception_handler.cc, signal.h is already included earlier, so
we can drop the sys/signal.h include.
Bug: google-breakpad:631
Change-Id: If36d326453e3267d38a5b92ed1301f828e46befe
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2097344
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This reverts commit 0c0e24f709.
Reason for revert: This is causing breakage on CrOS due to unhandled
enums and dwarf5 support is in limbo, so pull this back out for now.
Bug: google-breakpad:812
Change-Id: I22dd5d87efb8bc83596d51d15a6808c41afb3fd2
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2095872
Reviewed-by: Mark Mentovai <mark@chromium.org>
This reverts commit dbd454dbe4.
Reason for revert: The parent CL is causing breakage on CrOS due to
unhandled enums. Before we can revert that, we need to revert this.
Bug: google-breakpad:812
Change-Id: I7c2446f3cd8ed9f6411e90dbdd2434bc463b2f6c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2095798
Reviewed-by: Mark Mentovai <mark@chromium.org>
Previously, dump_syms produced warnings whenever a DW_AT_specification
or DW_AT_abstract_origin attribute was a forward reference. 47cd498384
allowed those attributes to carry forward references, removing the
warnings altogether. It was not correct to remove the warnings entirely.
References that do not point to valid DIEs should still produce
warnings, whether a back reference or a forward reference.
This reintroduces those warnings as appropriate.
Bug: google-breakpad:813
Test: dumper_unittest SimpleCU.UnknownAbstractOrigin,Specifications.BadOffset
Change-Id: Ie7222c7a1886bab31423f27e2fbcce93e69625b3
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2090103
Reviewed-by: Mike Frysinger <vapier@chromium.org>
- "sym-upload-v2" protocol now supports specifying a symbol file "type".
- Known types are "breakpad" (default option, previously this was only
effectively the only option), "elf", "pe", "macho", "debug_only", "dwp",
"pdb", and "dsym".
- When type other than breakpad is specified, sym_upload tool requires
the code_file and debug_id value (that it otherwise would have gotten
from the text of the Breakpad symbol file).
- This ultimately means that sym_upload can be used to upload native
symbol files now, in addition to Breakpad symbol files.
Change-Id: I3a331ba16f199d1d0025df735716ba5de298f522
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2078670
Reviewed-by: Mark Mentovai <mark@chromium.org>
- Didn't used to support statically linked libcurl, now it does (like
HttpUpload does).
Change-Id: Ic014548225b129f0c1c9ffe6a671f5bd2352b6e6
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2068947
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Previously, the processor truncated the upper of two
overlapping module ranges to compensate for incorrect
reporting of module ranges by the Breakpad client.
Crashpad correctly reports module load ranges, so
this truncation strategy is no longer necessary.
However, when partitioned libraries are used, the base
library may have a range which encompasses the other
partitions. When this is combined with the truncate
upper merge strategy, the base library's executable
segment is truncated causing symbolization failures.
This patch changes Android's merge strategy to truncate
the lower range (which is still the base library, but
this strategy truncates from the high end of the
library's range, instead of its base).
Bug: b/149845120
Change-Id: Ic75ecd3e919432690740eb21ebd4265fc0bbaa86
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2067952
Reviewed-by: Mark Mentovai <mark@chromium.org>
* Renamed convert_UTF.c to convert_UTF.cc
* Enabled to use C++17 for [[clang::fallthrough]] defined in src/common/macros.h
Patch by Hiro Komatsu
Change-Id: I5de7f7dd4c8bf231a004144a5c82828c59ddcfd6
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/2026761
Reviewed-by: Mark Mentovai <mark@chromium.org>
Stackwalk can't recover caller's register X30($LR) value by STACK CFI info.
This will lead unwinding stop immediately when fallback to frame pointer unwinder.
This PR will use try to use second last frame to recover register X30($LR) by frame pointer.
And we will give up correction if STACK CFI info doesn't agree with frame pointer info.
Bug: https://bugs.chromium.org/p/google-breakpad/issues/detail?id=808
Change-Id: I50649e3398e268b02ff297e83db21d05705c2a2d
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1992641
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
When __DARWIN_OPAQUE_ARM_THREAD_STATE64 is set (by default when building
for arm64e), fp, lr, sp, pc, and flags (but not x or cpsr) in thread
state are prepended with "__opaque" and intended to be accessed via
supplied getters which may also authenticate pointers. We don't want to
authenticate those pointers (since we expect they may be invalid and
want to recover those invalid values) so access them directly.
Bug: b/140375065
Change-Id: Ibe6c1dbfb5d68a9d350614445fa06d48873f8549
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1986868
Reviewed-by: Mark Mentovai <mark@chromium.org>
DW_AT_specification and DW_AT_abstract_origin attributes carry
references to other DIEs. Nothing prevents the DIEs referred to from
appearing later in .debug_info than the DIE containing the referring
attribute, but dump_syms incompletly implemented its handling of these
references, and was only able to resolve them when they were
back-references.
This will fix the chronic warnings produced by dump_syms of the form:
dump_syms: the DIE at offset <offset> has a {DW_AT_specification,
DW_AT_abstract_origin} attribute referring to the die at offset
<offset>, which either was not marked as {a declaration, an inline}, or
comes later in the file
Patch by Greg Clayton
Bug: breakpad:441
Change-Id: I98957d64a234c22afb6d0153f1bdc09e6a600b1d
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1946706
Reviewed-by: Mark Mentovai <mark@chromium.org>
Fix compilation of http_upload.cc with Windows gcc after 548ca6e3, by
moving the definition of GetFileContents(), so it comes after the
definition of WideToMBCP(), which it uses (under !_MSC_VER).
common/windows/http_upload.cc: In function ‘bool {anonymous}::GetFileContents(const wstring&, std::vector<char>*)’:
common/windows/http_upload.cc:80:19: error: ‘WideToMBCP’ was not declared in this scope
Change-Id: I1646b39263e97bbf3bd8cb1ae209be238023110f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1928929
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This code indicates termination under “kill” semantics due to a module’s
code signature becoming invalid.
Bug: chromium:1023239
Change-Id: I3d453af9ef6c6925edcf9c08dbd78e563877522f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1930177
Reviewed-by: Robert Sesek <rsesek@chromium.org>
The file GTMLogger shipped with breakpad is a copy of the version
from google_toolbox_for_mac. Having uploader.mm depend on GTMLogger
causes pain to iOS projects that want to integrate both breakpad
and google_toolbox_for_mac.
Since the file uploader.mm mixed uses of fprintf and GTMLogger to
log errors and warning, convert it to only use fprintf to stderr.
Bug: none
Change-Id: I68313ccf6951676a2859f44225281813722096ba
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1911755
Reviewed-by: Mark Mentovai <mark@chromium.org>
A recent commit converted some source from C to C++. Chrome has
checks against unannotated switch case fallthroughs in C++ code, so the
converted source needs annotations.
Bug: 990190
Change-Id: Ib92435b4877be936f837928a70b552ec4975d42a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1898429
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
This reverts commit 07411862ea.
We were a bit overzealous in removing “register” here. Both clang and
GCC correctly disallow “register” as a storage class specifier in C++17
mode by producing an error in ordinary use. However, they require
“register” to be specified for explicit register variables, and do not
produce an error in this case.
Change-Id: I223f2652c6da4215d6e8788d902e767c94b8c29d
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1894875
Reviewed-by: Mark Mentovai <mark@chromium.org>
3e56ef9d changed dump_syms to set the module name from DT_SONAME
expecting that clients were already using DT_SONAME when it was
present. The Breakpad client previously only used DT_SONAME as the name
for a module if it detected that it was likely mapped from a zip file.
This patch updates the Breakpad Linux client to always use the
DT_SONAME in minidumps if it's present.
Also included are changes to address comments that were missed from
that review.
Bug: 1016924
Change-Id: I4aae8c05e6793d4b0598049a8964ddd4cb0c6194
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1889231
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Make the following consistent within the file:
- 0x...ULL for unsigned literals.
- On pointers, put the asterisk with the type.
Context: Made a previous change and saw a mix of styles. Make it
consistent for the sake of visual consistency.
Bug: None
Change-Id: I0f80aedc0ca0295be3c70bd88822cbb82d0415ba
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1888434
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
Partitioned libraries generated with lld and llvm-objcopy currently
contain a superset of debug information, beyond what applies to the
library itself. This is because objcopy cannot split up debug
information by partition - instead, it places a copy of all debug
information into each partition.
In lieu of potential future support for lld or objcopy becoming able to
split up debug information, let dump_syms do the next best thing:
- Find the address ranges of all PT_LOAD segments in the lib.
- Supply these to the Module being generated.
- Filter additions to the Module based on these ranges.
Bug: 990190
Change-Id: Ib5f279f42e3f6ea79eed9665efbcc23c3c5d25dc
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1884699
Reviewed-by: Joshua Peraza <jperaza@chromium.org>
The Breakpad and Crashpad clients will use an object's DT_SONAME as
the name for a module if it exists. Previously, linux dump_syms would
assume the basename of an input elf file matches that value, causing
symbol lookups to fail if they were mismatched. This patch updates
dump_syms to use DT_SONAME as the module name, if present.
Bug: 1016924
Change-Id: I5eff0cf06c703841df3fb552cb5a8e1e50a20c64
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1876763
Reviewed-by: Mike Frysinger <vapier@chromium.org>
"register" as a storage class specifier has been deprecated since C++11,
and has been removed from C++17 while remaining a reserved word. See
C++17 5.11 and C.4.3.
Change-Id: I2dbab8a7061cb680d902644d39ea1a7fbc930e5c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1749329
Reviewed-by: Mike Frysinger <vapier@chromium.org>
A .dSYM may validly contain a __DWARF segment without any __debug_info
section. This can occur for Chromium Framework in a component build of
Chromium, because in that case, all of the code is in other libraries
that Chromium Framework depends on.
This was previously tested by an assertion, but the assertion did not
trigger in NDEBUG (release) builds. In NDEBUG builds, this condition
would lead to an out-of-bounds read, detected by AddressSanitizer.
Instead of an assertion, the check is now always done at runtime.
Instead of being fatal, it's now just a warning, because it's been
established that __DWARF without __debug_info can occur.
(In the Chromium case, it remains pointless to run dump_syms via the
"chrome_dump_syms" target on a component build, as it'll only attempt to
symbolize Chromium Framework, and not any of the libraries that Chromium
Framework depends on that actually contain the code.)
Bug: chromium:991206
Change-Id: I6c9c75f0be7901813e3eaae54aff38c1afe73ca9
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1741610
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Since target_ptr is of type uint16_t* already, we don't need to scale
the byte count as the language does that for us. If it were void*, we
would need this code, but it's not.
In practice it's probably not a big deal due to how we preallocated
memory: when converting UTF8->UTF16, we'd reserve the same number of
code units, and UTF8 takes more code units per codepoint than UTF16,
so the UTF16 vector is always oversized.
When converting UTF32->UTF16, we also reserve the same number of
code units, but since one UTF32 code unit could require two UTF16
code units (for U+10000 codepoints and higher), we would probably
corrupt memory in the process. The APIs in this module don't seem
to take into account that range in general, so for now I'm only
fixing the memory corruption.
Bug: google-breakpad:768
Change-Id: Ibfaea4e866733ff8d99b505e72c500bd40d11a74
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1732888
Reviewed-by: Mark Mentovai <mark@chromium.org>
Pointer authentication codes are used to validate pointers against
accidental or malicious modification by storing a hash of the address
and a secret value in the pointer's unused, upper bits. The exact
bits used may vary by implementation and depend on the size of the
virtual address space of the target system, and whether other tagged
pointer features are in use.
Apple has implemented PACs in the Apple A12.
https://developer.apple.com/documentation/security/preparing_your_app_to_work_with_pointer_authentication
The documented method of stripping PACs from a pointer is to call
ptrauth_strip(), which ultimately emits an `xpaci` instruction, but
this option isn't available to the Breakpad processor not running on
the device. Instead, this patch selects likely address bits from
link register values by examining the address range of loaded modules.
Change-Id: I054bd1a03605719937fc85dcc8d8b9fe927f44be
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1713650
Reviewed-by: Mark Mentovai <mark@chromium.org>
Now decoding the OS name and exception codes for Fuchsia. Still not decoding exception flags (can be added later, if needed).
Change-Id: If66cb000828be18f0c1b35d1b1f52b3ca3e1fd67
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1699049
Reviewed-by: Mark Mentovai <mark@chromium.org>
- I think I previously fixed this for dump_syms, but must have missed
the symupload one because it didn't have a gn target.
Change-Id: Ibf4daa0dc874f329c2ee7c7b3d4de1ee6bc68d13
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1682717
Reviewed-by: Mark Mentovai <mark@chromium.org>
- This is a workaround to an issue with gn/clang build of Windows
symbol converter where dbghelp.dll is loaded from system32/syswow64
instead of alongside the process exe.
- Why do we care where dbghelp.dll is loaded from? Two considerations:
1. dbghelp.dll will only load symsrv.dll from the directory where it
resides.
2. symsrv.dll requires a file called "symsrv.yes" to be in the
directory where it resides in order to work with MS symbol stores.
Therefore if we load dbghelp.dll from syswow64, then we must also
ensure there is a symsrv.dll and symsrv.yes file in syswow64.
Change-Id: Ia283a2c11e276c855a48157aa7be77897af4b02e
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1680670
Reviewed-by: Mark Mentovai <mark@chromium.org>
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
- Only 64-bit PEs supported.
- Re-add some scripts that were missed in initial move of code.
- Change msdia120.dll dependency to msdia140.dll.
- Add tests for Intel, AMD, and NVidia Microsoft Symbol Stores.
- Windows symbol converter now attempts to fall back to PE-only metadata
when it fails to locate a PDB.
- Remove the 'binary' folder under converter_exe. Need to think more
about how a deployment should look and what tool(s) to use in creating
one.
Change-Id: I52e42cbe5e759874a25114c2483e8b50d73fdf77
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1670098
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
- Add a #define to testing.gyp to avoid warnings about TR1 deprecation.
- PESourceLineWriter now reads debug_file from CodeView record instead
of using code_file value.
- Updated PE-only MD reading unit test.
Change-Id: Ib4e6201df3e3fd651e160f310584b5a67b16c842
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1668347
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
- Rename two files from '.cpp' to '.cc' and insert missing comma in
between lines in source files list.
Change-Id: I169a738b565f52292cb0292b34c4397e9dc05370
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1666351
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
- First step, this is just enough to get it generating a msbuild
project with GYP, which in turn can build the executable.
- Tests need to be redesigned because there isn't an available server.
Change-Id: I45440fd32b3ede29666c127703bcd441f0e4288e
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1661134
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
- Implement in common_windows_lib-- added class "PESourceLineWriter".
- Add command-line switch to tell dump_syms to use PESourceLineWriter.
Symbol data created this way will contain information to correlate the
module with ones found in minidumps, along with frame info that allows
much higher quality stack-walking in those minidumps.
- Significant refactor of PDBSourceLineWriter-- all code concerned with
extracting metadata from PE files has been moved into utility
functions. This is to allow sharing of this functionality with newly-
added PESourceLineWriter.
- Added a unit test to dump_syms for the PE-only scenario.
Change-Id: If0855f05d424d32d23f484995be5f34232179a37
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1525325
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
ELF modules are loaded in memory in several, possibly discontiguous,
segments. If the holes between segments are large enough, other things,
possibly other ELF modules may be mapped in that space. Crashpad
records the range of modules as the base address of the lowest mapped
segment to the high address of the highest mapped segment. This means
that when one module is mapped into a hole in another, it appears to
the Breakpad processor as overlapping modules. Module ranges are
relevant to the Breakpad processor during stackwalking for identifying
which module a particular program counter belongs to (i.e. mapping the
address to a module's text segment). This patch addresses this issue of
overlapping modules by truncating the range of the module with the
lower base address. A typical module's text segment is the first loaded
segment which would leave the text segment range unaffected. Module
producers can restrict the size of holes in their ELF modules with the
flag "-Wl,-z,max-page-size=4096", preventing other modules from being
mapped in their address range.
Properly contemplating ELF module address ranges would require
extensions to the minidump format to encode any holes.
crbug.com/crashpad/298
This patch also renames the concept of "shrinking down" (which
truncated the upper of two overlapping ranges) to "truncate upper".
Change-Id: I4599201f1e43918db036c390961f8b39e3af1849
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1646932
Reviewed-by: Mark Mentovai <mark@chromium.org>
The path NSCachesDirectory may change across app updates and sometimes
even across app launches. As a result, the Config-XXX files may end up
with an outdated path to the associated minidump file.
Change-Id: I0befde26b2ac406c154ce7c7e9be0063ee99892d
Bug:850379
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1592561
Reviewed-by: Mark Mentovai <mark@chromium.org>
This CL adds a result callback on report upload completion.
On failure, Breakpad deletes the configuration file and does retry to
upload a report.
Using this callback, the client will be able to log some metrics and to
act on upload failure.
Bug: 954175
Change-Id: I95a3264b65d4c06ba5d8dde8377440d23f1e2081
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1572661
Reviewed-by: Mark Mentovai <mark@chromium.org>
Chrome's test runner on Linux installs its own StackDumpSignalHandler
which swallows signals and doesn't re-raise them. This is sloppy, but
apparently there are reasons (https://crbug.com/551681). For
breakpad_unittests, it causes problems where a test process expects (via
waitpid()) to observe a child crash. Deal with those cases by
explicitly restoring the default signal handler.
In another case, Chrome's test runner seems to have been arriving at the
conclusion that it was to expect output from a child. Transitioning from
exit() to _exit() fixes this problem, and it's not necessarily a bad
idea to do this in post-fork() children without an execve() anyway.
Bug: chromium:949098
Change-Id: I5a6af0c2a09cd8eac9998358f6d5ea665288236f
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1575670
Reviewed-by: Mark Mentovai <mark@chromium.org>
Running this test on android-kitkat-arm-rel fails for some reason:
[ RUN ] LinuxCoreDumperTest.VerifyExceptionDetails
linux_core_dumper_unittest.cc:170: Failure
Expected: (0U) != (dumper.crash_address()), actual: 0 vs 0
linux_core_dumper_unittest.cc:178: Failure
Expected equality of these values:
2U
Which is: 2
info.size()
Which is: 0
[ FAILED ] LinuxCoreDumperTest.VerifyExceptionDetails (7 ms)
Disable it for now on Android until someone can look into it.
Bug: google-breakpad:791
Change-Id: I40a5e3dbeeb44e5eb0df187e61d55e07d8ad3613
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1546778
Reviewed-by: Mark Mentovai <mark@chromium.org>
Some of the fields we save might have signed types depending on the
system (e.g. `typedef int pid_t`). Depending on the toolchain, we
can trip -Werror=narrowing failures like:
src/client/linux/minidump_writer/linux_core_dumper.cc:248:66: error:
narrowing conversion of ‘(__pid_t)info->siginfo_t::_sifields.siginfo_t::<anonymous union>::_kill.siginfo_t::<anonymous union>::<anonymous struct>::si_pid’
from ‘__pid_t {aka int}’ to ‘long unsigned int’ inside { } [-Werror=narrowing]
set_crash_exception_info({info->si_pid, info->si_uid});
^^^^^^
src/client/linux/minidump_writer/linux_core_dumper.cc:252:71: error:
narrowing conversion of ‘(int)info->siginfo_t::_sifields.siginfo_t::<anonymous union>::_sigsys.siginfo_t::<anonymous union>::<anonymous struct>::_syscall’
from ‘int’ to ‘long unsigned int’ inside { } [-Werror=narrowing]
set_crash_exception_info({info->si_syscall, info->si_arch});
^^^^^^^^^^
Since the exception info fields are all uint64_t which should be large
enough to handle all the fields in the siginfo_t structure, add casts
for all the assignments to avoid these errors. We have implicit casts
even without them, so we aren't changing behavior.
Bug: google-breakpad:791
Bug: chromium:945653
Change-Id: Ib04e015998f08b857159ac13e9a065a66d228d49
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1544862
Reviewed-by: Mark Mentovai <mark@chromium.org>
Even 64-bit Mach-O (MH_MAGIC_64 = 0xfeedfacf) is not a fully 64-bit file
format. File offsets in sections are stored in 32-bit fields, with
Mach-O writers typically truncating offsets too large to fit to just
their low 32 bits. When a section begins at a file offset >= 4GB,
dump_syms would produce an error such as:
Google Chrome Framework.dSYM/Contents/Resources/DWARF/Google Chrome Framework: the section '__apple_names' in segment '__DWARF' claims its contents lie outside the segment's contents
As a workaround, this implements the strategy I first described in
https://crbug.com/940823#c22.
Segment file offsets are stored in 64-bit fields. Because segments
contain sections and must load contiguously, it’s possible to infer a
section’s actual offset by computing its load address relative to its
containing segment’s load address, and treating this as an offset into
the containing segment’s file offset. For safety, this is only done for
64-bit segments (LC_SEGMENT_64) where the 32-bit section offset stored
in the Mach-O file is equal to the low (truncated) 32 bits of the
section offset recomputed per the above strategy.
Beware that this does not provide full “large file” support for 64-bit
Mach-O files. There are other file offsets within Mach-O files aside
from section file offsets that are stored in 32-bit fields even in the
64-bit format, including offsets to symbol table data (LC_SYMTAB and
LC_DYSYMTAB). No attempt is made to recover correct file offsets for
such data because, at present, such data is always stored by dsymutil
near the beginning of .dSYM files, within the first 4GB. If it becomes
necessary to address these other offsets, it should be possible to
recover these offsets by reference to the __LINKEDIT segment that
normally contains them, provided that __LINKEDIT doesn’t span more than
4GB, according to the strategy discussed at the bottom of
https://crbug.com/940823#c22.
Although this is sufficient to allow dump_syms to interpret Chromium
.dSYM files that exceed 4GB, be warned that these Mach-O files are still
technically malformed, and most other tools that consume Mach-O files
will continue to have difficulties interpreting these large files.
As further warning, note that should any individual DWARF section exceed
4GB, internal section offsets will be truncated irrecoverably, unless
and until the toolchain implements support for DWARF64.
https://bugs.llvm.org/show_bug.cgi?id=14969
With this change, dump_syms is able to correctly recover file offsets
from and continue processing a .dSYM file with length 4530593528
(4321MB), whose largest section (__DWARF,__debug_info = .debug_info) has
size 0x8d64c0b8 (2262MB), and which contains four sections (starting
with __DWARF,__apple_names) beginning at file offsets >= 4GB.
Bug: chromium:940823, chromium:946404
Change-Id: I23f5f3b07773fa2f010204d5bb53b6fb1d4926f7
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1541830
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
- Baselines appeared to be stale. dump_syms now prints FUNC entries
with the full function signature, whereas the baselines only
contained the function name. The current state of the symbol file
docs
(https://chromium.googlesource.com/breakpad/breakpad/+/refs/heads/master/docs/symbol_files.md)
seem to agree with the new FUNC entries rather than the old ones.
Example of a name given in current docs:
"nsQueryInterfaceWithError::operator()(nsID const&, void**) const".
Change-Id: I9e01354cd82b7184b7cba31d132603e949a657ac
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1529133
Reviewed-by: Ivan Penkov <ivanpe@chromium.org>
If the kernel/C library headers are old, they might not have the
fields needed for SIGSYS decoding. Add ifdef checks for that and
skip the logic entirely. Easier than adding arch-specific siginfo
structs to the codebase.
Bug: google-breakpad:791
Change-Id: Ia473e3ffa61fce4c42cf4c1e73a9df044599bc5c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1524447
Reviewed-by: Mark Mentovai <mark@chromium.org>
Many signals in Linux support additional metadata on a per-signal
basis. We can extract that from NT_SIGINFO and pass it through
in the exception_information fields.
The current core dumper logic doesn't set exception_information
at all, so this is an improvement.
Bug: google-breakpad:791
Change-Id: I38b78d6494e9bc682441750d98ac9be5b0656f5a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1497662
Reviewed-by: Mark Mentovai <mark@chromium.org>
