aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* Write adjusted range back to moduleTao Bai2016-05-032-0/+13
| | | | | | | | | | | | | | | | | In Android, the mmap could be overlapped by /dev/ashmem, we adjusted the range in https://breakpad.appspot.com/9744002/, but adjusted range isn't written back to module, this caused the corresponding module be dropped in BasicCodeModules copy constructor. This also fix a lot of 'unable to store module' warnings when dumping Android's minidump. BUG=606972 R=mark@chromium.org, wfh@chromium.org Review URL: https://codereview.chromium.org/1939333002 . Patch from Tao Bai <michaelbai@chromium.org>.
* Add parentheses to silence clang warningPrimiano Tucci2016-05-031-1/+2
| | | | | | | | | | | | | | | | | | | | | crrev.com/1887033002 introuced a clang warning (see below). This fixes it, so that breakpad can be rolled in chrome, where warnings are always fatal. From: https://build.chromium.org/p/tryserver.chromium.android/builders/android_chromium_gn_compile_dbg/builds/59031/steps/compile%20%28with%20patch%29/logs/stdio FAILED: clang_x64/obj/breakpad/dump_syms/dwarf_cu_to_module.o ../../breakpad/src/common/dwarf_cu_to_module.cc:420:20: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses] if (declaration_ && qualified_name || (unqualified_name && enclosing_name)) { ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~ ~~ ../../breakpad/src/common/dwarf_cu_to_module.cc:420:20: note: place parentheses around the '&&' expression to silence this warning if (declaration_ && qualified_name || (unqualified_name && enclosing_name)) { ^ ( ) R=mark@chromium.org, petrcermak@chromium.org Review URL: https://codereview.chromium.org/1928363002 .
* Revert of Extend mapping merge to include reserved but unused mappings. ↵Primiano Tucci2016-04-281-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (https://breakpad.appspot.com/7714003) Reason for revert: It is causing breakpad crash reports to be invalid (see the associated bug). Merging empty holes in r-x mappings was originally introduced in https://breakpad.appspot.com/7714003 to deal with the first generation of relro packing, which could introduce holes within a .so mapping: [libchrome.so] [guard region] [libchrome.so] However, the logic is broken for the case of two *different* adjacent .so mappings with a guard region in the middle: [libfoo.so] [guard region] [libchrome.so] In this case the guard region is mistakenly associated with libfoo.so, but that is not the right thing to do. In fact, the second generation of rerlo packing added the guard region to prevent mmaps from overlapping and to give room for the non-zero vaddr of relro-packed libraries, which require an anticipated load bias. As the first generation of relro packing is not used anymore, there is no reason to keep this buggy code, which causes failures in decoding crashes where an arbitrary library is mapped immediately before a rerlo packed library. Original issue's description: > Extend mapping merge to include reserved but unused mappings. > > When parsing /proc/pid/maps, current code merges adjacent entries that > refer to the same library and where the start of the second is equal to > the end of the first, for example: > > 40022000-40025000 r-xp 00000000 b3:11 827 /system/lib/liblog.so > 40025000-40026000 r--p 00002000 b3:11 827 /system/lib/liblog.so > 40026000-40027000 rw-p 00003000 b3:11 827 /system/lib/liblog.so > > When the system linker loads a library it first reserves all the address > space required, from the smallest start to the largest end address, using > an anonymous mapping, and then maps loaded segments inside that reservation. > If the loaded segments do not fully occupy the reservation this leaves > gaps, and these gaps prevent merges that should occur from occurring: > > 40417000-4044a000 r-xp 00000000 b3:11 820 /system/lib/libjpeg.so > > 4044a000-4044b000 ---p 00000000 00:00 0 > 4044b000-4044c000 r--p 00033000 b3:11 820 /system/lib/libjpeg.so > 4044c000-4044d000 rw-p 00034000 b3:11 820 /system/lib/libjpeg.so > > Where the segments that follow this gap do not contain executable code > the failure to merge does not affect breakpad operation. However, where > they do then the merge needs to occur. Packing relocations in a large > library splits the executable segment into two, resulting in: > > 73b0c000-73b21000 r-xp 00000000 b3:19 786460 > /data/.../libchrome.2160.0.so > > 73b21000-73d12000 ---p 00000000 00:00 0 > 73d12000-75a90000 r-xp 00014000 b3:19 786460 > /data/.../libchrome.2160.0.so > 75a90000-75c0d000 rw-p 01d91000 b3:19 786460 > /data/.../libchrome.2160.0.so > > Here the mapping at 73d12000-75a90000 must be merged into 73b0c000-73b21000 > so that breakpad correctly calculates the base address for text. > > This change enables the full merge by also merging anonymous maps which > result from unused reservation, identified as '---p' with offset 0, and > which follow on from an executable mapping, into that executable mapping. > > BUG=chromium:394703 BUG=chromium:499747 R=primiano@chromium.org, rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1923383002 .
* Remove GTM_ENABLE_LEAKS and GTMGarbageCollectionDave MacLachlan2016-04-212-74/+0
| | | | | | | | | Removes some archaic Google Toolbox For Mac features. BUG= R=ivanpe@chromium.org, mark@chromium.org Review URL: https://codereview.chromium.org/1912473002 .
* Make x86-64 frame pointer unwinding stricterTed Mielczarek2016-04-192-51/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The x86-64 frame pointer-based unwind method will accept values that aren't valid for the frame pointer register and the return address. This fixes it to reject non-8-byte-aligned frame pointers, as well as non-canonical addresses for the return address it finds. A colleague of mine asked me why Breakpad gave a bad stack for a crash in our crash-stats system: https://crash-stats.mozilla.com/report/index/a472c842-2c7b-4ca7-a267-478cf2160405 Digging in, it turns out that the function in frame 0 is a leaf function, so MSVC doesn't generate an entry in the unwind table for it, so dump_syms doesn't produce a STACK CFI entry for it in the symbol file. The stackwalker tries frame pointer unwinding, and %rbp is set to a value that sort-of works, so it produces a garbage frame 1 and then is lost. Either of the two checks in this patch would have stopped the stackwalker from using the frame pointer. It's possible we could do something smarter on the dump_syms side, like enumerating all functions and outputing some default STACK CFI rule for those that don't have unwind info, but that wouldn't fix crashes from existing builds without re-dumping symbols for them. In any event, these checks should always pass for valid frame pointer-using functions. R=mark@chromium.org BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1263001 Review URL: https://codereview.chromium.org/1902783002 .
* Bump MinidumpMemoryRegion::max_bytes to 2MBTed Mielczarek2016-04-141-1/+1
| | | | | | | BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=694 R=mark@chromium.org Review URL: https://codereview.chromium.org/1883253002 .
* Add a missing const to an accessor.Sebastien Marchand2016-04-141-1/+1
| | | | | | R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1882833004 .
* Fix DWARF handling of inlined functions in namespacesTed Mielczarek2016-04-142-9/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently an inlined function in a namespace in DWARF will be given a name comprised of just `namespace::`. This is due to a logic error in ComputeQualifiedName, where it doesn't handle an empty `unqualified_name` properly. We apparently have a fair number of these in our Mac builds, an example of the DWARF that's being mishandled looks like: 0x117eda40: TAG_namespace [5] * AT_name( "js" ) AT_decl_file( "../../dist/include/js/Utility.h" ) AT_decl_line( 35 ) 0x11808500: TAG_subprogram [251] * AT_low_pc( 0x0000000002f12110 ) AT_high_pc( 0x0000000002f1216b ) AT_APPLE_omit_frame_ptr( 0x01 ) AT_frame_base( rsp ) AT_abstract_origin( {0x0000000011800a4f}"_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" ) AT_MIPS_linkage_name( "_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" ) AT_name( "TraceManuallyBarrieredGenericPointerEdge" ) AT_decl_file( "/builds/slave/rel-m-rel-m64_bld-000000000000/build/js/src/gc/Marking.cpp" ) AT_decl_line( 547 ) AT_external( 0x01 ) AT_APPLE_optimized( 0x01 ) AT_inline( DW_INL_inlined ) This turned a few instances of this in the file I was testing on into `<name omitted>`, which seems to just be a symptom of the "DW_AT_abstract_origin comes later in the file" issue. (Which is probably also worth fixing given that it occurs some 29k times when dumping symbols from Firefox's XUL binary, but it's a separate issue.) R=mark@chromium.org BUG= Review URL: https://codereview.chromium.org/1887033002 .
* Add some new stream types to MDStreamTypeTed Mielczarek2016-04-132-0/+12
| | | | | | | | | | | | | | I ran minidump_dump on a dump from Firefox on my Windows 10 machine and noticed some streams that Breakpad didn't have names for. Looking in minidumpapiset.h in the Windows 10 SDK finds these values in MINIDUMP_STREAM_TYPE. There are also struct definitions for the stream data for some of them (all but JavaScriptData), but I don't have a particular need for those currently. R=mark@chromium.org BUG= Review URL: https://codereview.chromium.org/1884943002 .
* Fix a dependency issue in automakeTed Mielczarek2016-04-121-0/+3
| | | | | | | | | | | | | Doing a `make -jN check` from a fresh build breaks (and has probably been broken for a while). linux_client_unittest_shlib is missing $(TEST_LIBS) from its _DEPENDENCIES. The automake manual says if _DEPENDENCIES are not specified they'll be computed from _LDADD, but we are specifying it and just leaving out $(TEST_LIBS). R=vapier@chromium.org BUG= Review URL: https://codereview.chromium.org/1870733005 .
* tweak IGNORE_RET behavior a bitMike Frysinger2016-04-111-1/+1
| | | | | | | | | | GCC will still warn about unused return value with the form: if (write(...)); Instead, change the semi-colon to an empty set of braces. BUG=chromium:428478 TEST=build+test still works
* Added an option (-i) to have dump_syms output header information only.David Yen2016-04-086-83/+188
| | | | | | | | | | | | | | | | | It is often helpful to check if a particular symbol file dumped by dump_syms actually matches a version of a binary file we have. The symbol output contains an ID which can be used to see if it matches the binary file. Unfortunately, this ID is internally calculated and not a standard hash of the binary file. Being able to output the header information only will allow users to determine whether their symbol file is up to date or not. R=jochen@chromium.org BUG=561447 Review URL: https://codereview.chromium.org/1864823002 . Patch from David Yen <dyen@chromium.org>.
* Remove unreferenced local variable which breaks build.Yunxiao Ma2016-04-051-3/+2
| | | | | | | | | | | | | Depending on compiler's setting, the unreferenced local variable may cause build break. modified: src/processor/minidump.cc R=mark@chromium.org Review URL: https://codereview.chromium.org/1866533002 . Patch from Yunxiao Ma <yxma@google.com>.
* Rename stdio.h wrapper file to stdio_wrapper.h.Yunxiao Ma2016-04-057-9/+9
| | | | | | | | | | | | | | | | | | | | 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>.
* Switch the Linux minidump writer to use MDCVInfoELF for CV data.Ted Mielczarek2016-04-0514-224/+452
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 .
* Support processing microdump for mips architectureVeljko Mihailovic2016-04-017-6/+254
| | | | | | | | | | Based on changes for ARM, ARM64 and X86, the support for MIPS and MIPS64 is added in microdump. TEST=microdump_stackwalk ~/microdump-mips32.dmp symbols/ BUG=microdump_stackwalk failing for mips architectures Review URL: https://codereview.chromium.org/1731923002/
* Add the TID to the CallStack.Sebastien Marchand2016-04-014-1/+14
| | | | | | R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1849933002 .
* Refactor sym_upload in tools to extract code into common/linux, and minor fixesLi Yan2016-03-305-129/+234
| | | | | | | | | | | | to code calling libcurl. This change may be used to build a tool to dump and upload symbols with multi-thread. BUG= R=mmandlis@chromium.org CC=google-breakpad-dev@googlegroups.com Review URL: https://codereview.chromium.org/1842113002 .
* Make EXC_BAD_ACCESS / EXC_I386_GPFLT print nicely in the processorTed Mielczarek2016-03-291-5/+21
| | | | | | | | | | | | | | | | | | | | | Currently EXC_BAD_ACCESS doesn't support EXC_I386_GPFLT as exception_flags for pretty-printing in the processor, but this happens for a lot of things: http://opensource.apple.com/source/xnu/xnu-2050.24.15/osfmk/i386/trap.c (search for EXC_I386_GPFLT). And we get a lot of these in the wild: https://crash-stats.mozilla.com/search/?reason=%3DEXC_BAD_ACCESS+%2F+0x0000000d&cpu_name=amd64&_facets=signature&_facets=address&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=address#crash-reports This patch makes them show up with a nice name instead of the current "EXC_BAD_ACCESS / 0x0000000d". Additionally, this patch fixes some other cases where x86-64 wasn't being handled in the same way as x86, and fixes some x86-specific exception flags to be stringified with I386 in the output. R=mark@chromium.org BUG= Review URL: https://codereview.chromium.org/1833123002 .
* Have dump_syms output the full symbol table.David Yen2016-03-231-18/+47
| | | | | | | | | | | | | | | | | | 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>.
* Explicitly call non-sized delete on dynamically sized memory for correct ↵Ivan Penkov2016-03-111-1/+1
| | | | | | | | | | | | | | | | behavior under sized-delete. The code as it stands allocates a chunk of memory of arbitrary size and places an object into it. It stores a pointer to that object and memory into a list telling the compiler that it is a pointer to a char. When the compiler deletes the objects in the list it thinks that the list contains pointers to chars - not pointers to arbitrarily sized regions of memory. This is fixing an issue that will reproduces when the following optimization (C++ sized dealocation) is enabled: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3536.html The fix is to explicitly call the non-sized delete operator, and the library code that supports malloc/free/new/delete will figure out the size of the block of memory from the pointer being passed in. Patch provided by Darryl Gove. R=mark@chromium.org Review URL: https://codereview.chromium.org/1788473002 .
* Fix format warning in omap.ccJon Turney2016-03-101-1/+1
| | | | | | | omap.cc(212): warning C4473: 'fprintf' : not enough arguments passed for format string BUG=None Review URL: https://codereview.chromium.org/1776613004
* Don't merge the mappings if their exec bit are different.Primiano Tucci2016-03-081-1/+2
| | | | | | | BUG=585534 R=primiano@chromium.org Review URL: https://codereview.chromium.org/1750033002 .
* Add an optional root prefix to Linux dumpersDominik Laskowski2016-03-077-35/+58
| | | | | | | | | | | The Linux dumpers use absolute paths for shared libraries referenced by dumps, so they fail to locate them if the crash originated in a chroot. This CL enables callers to specify a root prefix, which is prepended to mapping paths before opening them. BUG=chromium:591792 TEST=make check Review URL: https://codereview.chromium.org/1761023002/
* Handle multiple microdumps in system log.Maria Mandlis2016-02-263-4/+211
| | | | | | | | Properly handle microdump processing, when the system_log file contains an incomplete microdump section at the top. The processor will process the first complete microdump section. R=primiano@chromium.org Review URL: https://codereview.chromium.org/1742843002 .
* Support processing microdumps for x86 architecture.Maria Mandlis2016-02-184-6/+216
| | | | | | | BUG=587536 R=primiano@chromium.org Review URL: https://codereview.chromium.org/1704243002 .
* Try loading msdiaNNN.dll if CoCreateInstance(CLSID_DiaSource) failsBirunthan Mohanathas2016-02-171-4/+36
| | | | | | | | | | 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
* Fix buffer overrun in MinidumpModule::debug_identifier with MDCVInfoELFTed Mielczarek2016-02-171-1/+3
|
* Fixing a flaky Linux exploitability unittest.Ivan Penkov2016-02-163-15/+81
| | | | | | | BUG=https://code.google.com/p/chromium/issues/detail?id=584174 R=mmandlis@chromium.org Review URL: https://codereview.chromium.org/1697963002 .
* Ensure Linux minidump writer flushes minidump header early.Ted Mielczarek2016-02-121-11/+18
| | | | | | | | | | | | | | | | If the Linux minidump writer crashes while writing a dump, the dump might contain some useful information, but the header will be empty because TypedMDRVA's destructor flushes the data, and the header var doesn't go out of scope until the end of the `Dump` method. This fixes that problem by putting the header in a shorter block scope. We've seen this problem in some Android dumps in the wild, like: https://crash-stats.mozilla.com/report/index/cef5b777-02d1-43c2-bf40-133ab2160209 R=thestig@chromium.org BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1247978 Review URL: https://codereview.chromium.org/1696573003 .
* Parse additional line introduced in the microdump format and containing the ↵Maria Mandlis2016-02-1111-1/+56
| | | | | | | | | | | | | | | GPU infromation in the following format: 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 .
* Revert "Added a switch to dump minidump modules in minidump_stackwalk."Lei Zhang2016-02-103-30/+5
| | | | | | | | | | | This reverts commit cb936a0243c97ae9cd2d4bb19d95dde0421fed6d. A=dyen@chromium.org Original Review: https://codereview.chromium.org/1672773002/ R=dyen@chromium.org Review URL: https://codereview.chromium.org/1688493003 .
* Change MDCVInfoELF into something usable.Ted Mielczarek2016-02-104-45/+313
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes MDCVInfoELF (which is currently unused, apparently a vestigal bit of code landed as part of Solaris support) into a supported CodeView format that simply contains a build id as raw bytes. Modern ELF toolchains support build ids nicely: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/compiling-build-id.html It would be useful to have the original build ids of loaded modules in Linux minidumps, since tools like Fedora's darkserver allow querying by build id and the current Breakpad code truncates the build id to the size of a GUID, which loses information: https://darkserver.fedoraproject.org/ A follow-up patch will change the Linux minidump generation code to produce MDCVInfoELF in minidumps instead of MDCVInfoPDB70. This patch should be landed first to ensure that crash processors are able to handle this format before dumps are generated containing it. The full build id is exposed as the return value of Minidump::code_identifier(), which currently just returns "id" for modules in Linux dumps. For backwards-compatibility, Minidump::debug_identifier() continues to treat the build id as a GUID, so debug identifiers for existing modules will not change. BUG= R=mark@chromium.org Review URL: https://codereview.chromium.org/1675413002 .
* Fix usage of deprecated method sendSynchronousRequest:returningResponse:error:.Sylvain Defresne2016-02-081-3/+43
| | | | | | | | | | | | | The method -[NSURLConnection sendSynchronousRequest:returningResponse:error:] has been deprecated in 10.11 OS X SDK and 9.0 iOS SDK without replacement. So emulate a synchronous request by using an asynchronous request and waiting on a semaphore for the request completion. BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=675 BUG=569158 R=mark@chromium.org Review URL: https://codereview.chromium.org/1675243002 .
* Fix usage of deprecated method stringByAddingPercentEscapesUsingEncoding:.Sylvain Defresne2016-02-081-4/+19
| | | | | | | | | | | | | | | | 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 .
* Fix usage of deprecated function CFPropertyListCreateFromXMLData.Sylvain Defresne2016-02-081-3/+3
| | | | | | | | | | | | The function CFPropertyListCreateFromXMLData is deprecated in favor of the function CFPropertyListCreateWithData that is available since the 10.6 OS X SDK and 4.0 iOS SDK. BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=675 BUG=569158 R=mark@chromium.org Review URL: https://codereview.chromium.org/1678063002 .
* [mips64] Support for mips n64Mike Frysinger2016-02-0617-133/+1083
| | | | | | | | | | Adding remaining mips n64 support including stackwalker. BUG=None TEST=manually tested on Linux/Android R=vapier@chromium.org Review URL: https://codereview.chromium.org/1418453011 .
* Remove use of deprecated CFURLCreateDataAndPropertiesFromResource function.Ivan Penkov2016-01-311-6/+19
| | | | | | | | | | | | | Original change (https://codereview.chromium.org/1527363003/) was failing in CFReadStreamGetBuffer() call, so changed to CFReadStreamRead() to be more conservative. Patch provided by Scott Hancher. BUG= R=mark@chromium.org Review URL: https://codereview.chromium.org/1637433003 .
* Added a switch to dump minidump modules in minidump_stackwalk.Lei Zhang2016-01-293-5/+30
| | | | | | | | | | | | In order to figure out what symbols we need associated to a minidump, it is useful to be able to dump all the modules the minidump contains. A=dyen@chromium.org Original Review: https://codereview.chromium.org/1651593002/ BUG=563716 R=dyen@chromium.org Review URL: https://codereview.chromium.org/1650713002 .
* Improvements to GYP buildPavel Labath2016-01-293-3/+10
| | | | | | | | | | | | | | | | | | | | | | 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 .
* convert to uint8_t* for binary data to fix -Wnarrowing build errorsMike Frysinger2016-01-2616-173/+219
| | | | | | | | | | | | | | | 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 .
* test: allow use of system gmock/gtest libsMike Frysinger2016-01-251-2/+2
| | | | | | | | | | | | | | Some systems provide prebuilt copies of gmock/gtest (such as Chromium OS). Add a configure flag so they can take advantage of that. This allows for a smaller checkout as they don't need to include the full testing/ tree. BUG=chromium:579384 TEST=`make check` passes w/--enable-system-test-libs TEST=`make check` passes w/--disable-system-test-libs R=thestig@chromium.org Review URL: https://codereview.chromium.org/1638653002 .
* Revert "Fix deprecatation warning when building for recent SDKs on iOS/OS X."Olivier Robin2016-01-212-62/+10
| | | | | | | | | | | | | | | | | | | | 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>.
* exploitability_unittest: fix warningsMike Frysinger2016-01-211-7/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The std::getline function always returns its first arg (which is an iostream object) and cannot return anything else. Thus, testing its value is pointless, and even leads to build errors w/at least gcc-5 due to gtest ASSERT_TRUE funcs only taking bool types: .../exploitability_unittest.cc: In member function 'virtual void {anonymous}::ExploitabilityLinuxUtilsTest_DisassembleBytesTest_Test::TestBody()': .../exploitability_unittest.cc:200:136: error: no matching function for call to 'testing::AssertionResult::AssertionResult(std::basic_istream<char>&)' In file included from .../breakpad_googletest_includes.h:33:0, from .../exploitability_unittest.cc:35: .../gtest.h:262:12: note: candidate: testing::AssertionResult::AssertionResult(bool) Since we know this never fails, simply drop the ASSERT_TRUE usage. The next line already checks the content of the buffer we read. Further on in the file, we hit some signed warnings: In file included from .../breakpad_googletest_includes.h:33:0, from .../exploitability_unittest.cc:35: .../gtest.h: In instantiation of 'testing::AssertionResult testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const T2&) [with T1 = long unsigned int; T2 = int]': .../gtest.h:1484:23: required from 'static testing::AssertionResult testing::internal::EqHelper<lhs_is_null_literal>::Compare(const char*, const char*, const T1&, const T2&) [with T1 = long unsigned int; T2 = int; bool lhs_is_null_literal = false]' .../exploitability_unittest.cc:241:289: required from here .../gtest.h:1448:16: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] if (expected == actual) { This is because we compare the register value (a uint64_t) directly to an integer constant, and those are signed by default. Stick a U suffix on them to fix things up. BUG=chromium:579384 TEST=`make check` passes R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1611763002 .
* Fix usage of snprintf for MSVCPavel Labath2016-01-197-17/+50
| | | | | | | | | | | | | | 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>.
* breakpad: fix unittest failure when building with clang.Mike Frysinger2016-01-151-1/+1
| | | | | | | | | | | | | | | In C/C++, the result of signed integer overflow is undefined. The expression "base + size - 1" is parsed as "(base + size) - 1", and "base + size" can overflow even if "base + (size - 1)" <= INT_MAX. See http://g/c-compiler-chrome/461JohPKakE/JI3rEBg6FwAJ for more. BUG=None TEST='CC=clang CXX=clang++ ./configure && make check' R=vapier@chromium.org Review URL: https://codereview.chromium.org/1591793002 .
* libdisasm: Remove inclusion of windows.hPavel Labath2016-01-121-4/+0
| | | | | | | | | | | | | | windows.h defines exception_code as a macro, which conflicts with our use of the identifier in exception records. It appears that this particular include of windows.h is not needed, so instead of undefining the macro, I simply delete the include. Build tested with MSVC 2013. BUG= R=mark@chromium.org Review URL: https://codereview.chromium.org/1579623004 . Patch from Pavel Labath <labath@google.com>.
* Define intptr and uintptr in a more generic wayPavel Labath2016-01-111-6/+2
| | | | | | | | | | | | | 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>.
* libdisasm: Don't depend on sizeof(void)Pavel Labath2016-01-081-3/+3
| | | | | | | | | | | | | Due to operator precedence, the address was first cast to void* and then incremented, which resulted in an error on windows, as sizeof(void) is undefined and MSVC takes this seriously. Changing the precedence to perform the addition first. R=mark@chromium.org Review URL: https://codereview.chromium.org/1570843002 . Patch from Pavel Labath <labath@google.com>.
* disassembler_x86: Remove unused includePavel Labath2016-01-081-1/+0
| | | | | | | | | | | | | This file is not present on windows, and it's causing build errors there. As far as I can tell, nothing in this file actually uses that include, so I just remove it. BUG= R=mark@chromium.org Review URL: https://codereview.chromium.org/1475353002 . Patch from Pavel Labath <labath@google.com>.
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-06 14:20:07 +0000