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>.
This preserves full build ids in minidumps, which are useful for
tracking down the right version of system libraries from Linux
distributions.
The default build id produced by GNU binutils' ld is a 160-bit SHA-1
hash of some parts of the binary, which is exactly 20 bytes:
https://sourceware.org/binutils/docs-2.26/ld/Options.html#index-g_t_002d_002dbuild_002did-292
The bulk of the changes here are to change the signatures of the
FileID methods to use a wasteful_vector instead of raw pointers, since
build ids can be of arbitrary length.
The previous change that added support for this in the processor code
preserved the return value of `Minidump::debug_identifier()` as the
current `GUID+age` treatment for backwards-compatibility, and exposed
the full build id from `Minidump::code_identifier()`, which was
previously stubbed out for Linux dumps. This change keeps the debug ID
in the `dump_syms` output the same to match.
R=mark@chromium.org, thestig@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1688743002 .
Some of the symbols in the stack trace are not found in the .dynsym
section but were located in the full symbol table .symtab section
instead. This was causing some of our stack traces to be incomplete or
point to incorrect function names.
Since we only output function names, there are actually not that many
more symbols located in .symtab that aren't in .dynsym. It is better to
simply output all symbols found so our stack traces are complete.
R=mark@chromium.org, thestig@chromium.org
BUG=561447
Review URL: https://codereview.chromium.org/1824063002 .
Patch from David Yen <dyen@chromium.org>.
Because tools/windows/symupload/symupload.cc uses `nullptr` (which
requires VS2010), the CLSID comparison is only performed for msdia100.dll
and later. When compiling with an older (or future) CLSID_DiaSource, we
retain the existing behaviour (i.e. fail if CoCreateInstance fails).
R=ivanpe@chromium.org
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1236343
The method -[NSString stringByAddingPercentEscapesUsingEncoding:] has been
deprecated with 10.11 OS X SDK and 9.0 iOS SDK. The recommended method is
-[NSString stringByAddingPercentEncodingWithAllowedCharacters:] available
since 10.9 OS X SDK and 7.0 iOS SDK.
Use the new method when available using URLQueryAllowedCharacterSet to get
the same encoded string.
BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=675
BUG=569158
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1680663002 .
This updates the GYP build for the processor component (on windows).
- adds/removes references to files which were added or removed from the
repository
- includes build/common.gypi in the gyp files: needed to correctly
detect the OS (I think, the generated MSVC solutions were broken
without it)
- conditionally compiles code platform-specific code for the given
platform
After this minidump processor nearly compiles with VS2013: the generated
project is correct, but some files still have compilation errors.
Disclaimer: I have not tested the GYP changes on non-windows platform,
as there does not seem to be anyone using it there.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1643633004 .
Newer gcc versions default to -Werror=narrowing when using newer C++
standards (which we do). This causes issues when we try to stuff a
value like 0xea into a char -- the value is out of range for signed
char bytes. That's when gcc throws an error:
.../bytereader_unittest.cc: In member function 'virtual void Reader_DW_EH_PE_absptr4_Test::TestBody()':
.../bytereader_unittest.cc:400:55: error: narrowing conversion of '234' from 'int' to 'char' inside { } [-Wnarrowing]
BUG=chromium:579384
TEST=`make check` passes
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1605153004 .
This reverts CL https://codereview.chromium.org/1563223004/
This reverts commit 7cc0d8562bf8b20b88cc941ba72593cb7230ecf6.
CL 1563223004 introduces two bugs on iOS.
- Encoding the minidump name with extra percent causing crash server to fail
processing the file.
- Using a released pointer causing random crashes on upload. The
data, resp, err pointers returned in the NSURLSession completion
handler is released at the end of the block. When used later (to get
the crash ID), it causes a crash.
BUG=569158
R=blundell@chromium.org, mark@chromium.org
Review URL: https://codereview.chromium.org/1619603002 .
Patch from Olivier Robin <olivierrobin@chromium.org>.
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>.
MSVC does not have the __PTRDIFF_TYPE__ macro defined, so I use the
standard [u]intptr_t types instead. Compilation tested on windows, linux
and mac.
BUG=
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1571293003 .
Patch from Pavel Labath <labath@google.com>.
Fixes the following compilation warning when using recent version of
the iOS or OS X SDK by using the recommended new API:
../../breakpad/src/common/mac/HTTPMultipartUpload.m:56:10: error: 'stringByAddingPercentEscapesUsingEncoding:' is deprecated: first deprecated in iOS 9.0 - Use -stringByAddingPercentEncodingWithAllowedCharacters: instead, which always uses the recommended UTF-8 encoding, and which encodes for a specific URL component or subcomponent since each URL component or subcomponent has different rules for what characters are valid. [-Werror,-Wdeprecated-declarations]
[key stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
^
CFURLCreateStringByAddingPercentEscapes
../../breakpad/src/common/mac/HTTPMultipartUpload.m:207:29: error: 'sendSynchronousRequest:returningResponse:error:' is deprecated: first deprecated in iOS 9.0 - Use [NSURLSession dataTaskWithRequest:completionHandler:] (see NSURLSession.h [-Werror,-Wdeprecated-declarations]
data = [NSURLConnection sendSynchronousRequest:req
^
../../breakpad/src/client/mac/handler/minidump_generator.cc:158:6: error: 'CFPropertyListCreateFromXMLData' is deprecated: first deprecated in iOS 8.0 - Use CFPropertyListCreateWithData instead. [-Werror,-Wdeprecated-declarations]
(CFPropertyListCreateFromXMLData(NULL, data, kCFPropertyListImmutable,
^
BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=675
BUG=569158
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1563223004 .
This patch allows dump_syms to handle S_THREAD_LOCAL_ZEROFILL
and S_GB_ZEROFILL section in the same way as the more common
S_ZEROFILL section. Previously, dump_syms would fail to dump
a binary containing a __DATA,__thread_bss section, because it
tried to look up its data (and failed).
R=mark@chromium.org
Review URL: https://codereview.chromium.org/1369233003 .
Patch from Pavel Labath <labath@google.com>.
We're working on building our Firefox Mac builds as a Linux cross-compile
(https://bugzilla.mozilla.org/show_bug.cgi?id=921040) and we need symbol
dumping to work. This change ports the Mac dump_syms tool to build and work
on Linux. I've tested it and it produces identical output to running the
tool on Mac.
The bulk of the work here was converting src/common/mac/dump_syms.mm and
src/tools/mac/dump_syms/dump_syms_tool.mm from ObjC++ to C++ and removing
their use of Foundation classes in favor of standard C/C++.
This won't compile out-of-the-box on Linux, it requires some Mac system
headers that are not included in this patch. I have those tentatively in
a separate patch to land in Gecko
(http://hg.mozilla.org/users/tmielczarek_mozilla.com/mc/rev/5fb8da23c83c),
but I wasn't sure if you'd be interested in having them in the Breakpad tree.
We could almost certainly pare down the set of headers included there, I
didn't spend too much time trying to minimize them (we primarily just need
the Mach-O structs and a few associated bits).
I just realized that this patch is missing updating the XCode project files
(ugh). I'll fix that up in a bit.
R=mark@chromium.org
BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=543111
Review URL: https://codereview.chromium.org/1340543002 .
Android's sys/user.h is missing user_regs_struct and user_fpsimd_struct.
Add them to the Android specific user.h used by breakpad to workaround
Android / glibc compatibility issues.
A bug has been filed on the Android NDK team to add the missing structures to
the NDK, at which point this hack can be removed.
Also remove the mxcsr_mask hack on x64, which is no longer required since
we have moved to the r10d NDK which fixes this issue.
R=primiano@chromium.org
Review URL: https://codereview.chromium.org/1291983003 .
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1495 4c0a9323-5329-0410-9bdc-e9ce6186880e
Shared libraries containing Android packed relocations have a load
bias that differs from the start address in /proc/$$/maps. Current
breakpad assumes that the load bias and mapping start address are
the same.
Fixed by changing the client to detect the presence of Android packed
relocations in the address space of a loaded library, and adjusting the
stored mapping start address of any that are packed so that it contains
the linker's load bias.
For this to work properly, it is important that the non-packed library
is symbolized for breakpad. Either packed or non-packed libraries may
be run on the device; the client detects which has been loaded by the
linker.
BUG=499747
R=primiano@chromium.org, rmcilroy@chromium.org
Review URL: https://codereview.chromium.org/1189823002.
Patch from Simon Baldwin <simonb@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1459 4c0a9323-5329-0410-9bdc-e9ce6186880e
This is a reland of the previous CL (r1433). r1433 did not achieve what
intended and failed the x86_64 build of Chrome with NDK r10c.
The workaround logic in this CL is identical to r1433, but the #define
magic is applied in a more appropriate proper place this time. Turns
out Breakpad already has an Android compatibility layer, which is
common/android/include. Piggybacking the fix there.
BUG=breakpad:642
R=fdegans@chromium.org, rmcilroy@chromium.org
Review URL: https://breakpad.appspot.com/3794002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1434 4c0a9323-5329-0410-9bdc-e9ce6186880e
problems.
- The ordering of keys in stl containers cannot change. Make the relevant
members const to guarantee this assumption.
- Add handling and logging for demangle errors.
- Fix a potential double-delete bug if a function passed to AddFunction() is
already present.
BUG=chromium:449214
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/10704002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1415 4c0a9323-5329-0410-9bdc-e9ce6186880e
Previously, dump_syms did not handle DW_FORM_ref_addr if it appeared
in DWARF 4 debugging info.
Also fix a DW_FORM_ref_addr case so that it doesn't fall through to
the next switch case when assertions are disabled and the DWARF
version isn't recognised.
The following steps will reproduce the problem when using LLVM 3.4:
cat <<END >example1.c
int main() { return 0; }
END
cat <<END >example2.c
void foo(int x) {}
END
clang -emit-llvm -g -c example1.c -o example1.bc
clang -emit-llvm -g -c example2.c -o example2.bc
llvm-link-3.4 example1.bc example2.bc -o combined.bc
clang combined.bc -o executable
./google-breakpad/build/src/tools/linux/dump_syms/dump_syms executable
When using LLVM bitcode linking in this way, LLVM's backend generates
partially-merged DWARF debugging info in which some of the references
to the "int" type go via "DW_FORM_ref_addr". Since PNaCl uses LLVM
bitcode linking, this dump_syms failure occurs with nexes produced by
the PNaCl toolchain.
BUG= https://code.google.com/p/chromium/issues/detail?id=416368
TEST= see above
R=mark@chromium.org, mcgrathr@chromium.org
Review URL: https://breakpad.appspot.com/5744002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1408 4c0a9323-5329-0410-9bdc-e9ce6186880e
Adding an optional parameter --product to symupload.exe. If specified it will be passed to the symbol server as POST parameter 'product'.
As part of this, I'm also fixing:
- Removed the .vcproj file as it can be generated from the .gyp file on demand.
- error C4335: Mac file format detected. Fixed the line endings for omap.cc and dia_util.cc.
- warning C4003: not enough actual parameters for macro 'max'
Symupload.exe was compiled using MSVS 2013 and DIA SDK 12.0.
Review URL: https://breakpad.appspot.com/9734002/
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1402 4c0a9323-5329-0410-9bdc-e9ce6186880e
This change introduces the necessary glue typedefs to deal with the
mismatch introduced by the latest Android NDK (w.r.t. desktop Linux):
- [x86_64] Rename fpregs mxcr_mask -> .mxcsr_mask
- [mips] uc_mcontext.fpregs.fp_r.fp_dregs -> uc_mcontext.fpreg
- [mips] restore the forked user.h
Submitting this on behalf of fdegans@chromium.orgTBR=mark@chromium.org
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1397 4c0a9323-5329-0410-9bdc-e9ce6186880e
Prior to NDK r10c, Breakpad was privately backporting these system
headers. This change is now unforking and removing those headers and
using the ones from the NDK.
Rationale:
- They are finally available in the NDK, so there is no need to keep
maintaining a fork (which was necessary up until recently to support
arm64).
- These forked headers, as they are today, are not compatible with the
latest NDK (i.e. this change is required to roll NDK r10c).
The forked ucontext.h, being removed by this CL, depends on some
transitional features which are not compatible with the NDK release
being targeted here.
After this change, the NDK r10c is now required to build Breakpad on
Android. Note that NDK releases are backwards compatible and contain all
the previous API levels, so this change is NOT effectively enforcing to
build against any particular Android SDK.
Submitting this on behalf of fdegans@chromium.org
BUG=chromium:358831
R=mark@chromium.org, primiano@chromium.org, rmcilroy@chromium.org
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1396 4c0a9323-5329-0410-9bdc-e9ce6186880e
