aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
* [Android] Guard some NDK workarounds by major version.John Budorick2016-07-151-1/+11
| | | | | | | BUG=599327 R=mark@chromium.org Review URL: https://codereview.chromium.org/2152153003 .
* Add a new argument to specify the minidump type to write on Windows.Ting-Yu Chou2016-06-292-6/+10
| | | | | | | R=ted.mielczarek@gmail.com BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1267329 Review URL: https://codereview.chromium.org/2107083002/ .
* Server-side workaround to handle overlapping modules.Ivan Penkov2016-06-2018-39/+239
| | | | | | | | | | | | | | This change is resolving an issue that was caused by the combination of: - Android system libraries being relro packed in N+. - Breakpad dealing with relro packed libraries in a hack way. This is a fix for http://crbug/611824. I also found an use-after-free issue (bug in Minidump::SeekToStreamType). I disallowed the MinidumpStreamInfo copy and assign constructors and the compiler detected another similar issue in Minidump::Print. Then I disabled the copy and assign constructors for most classes in minidump.h (just in case). There are a couple of classes where I couldn't disallow them (since assign is used). This will require a small refactor so I left it out of this CL. R=mark@chromium.org Review URL: https://codereview.chromium.org/2060663002 .
* linux-syscall-support: pull in latest versionMike Frysinger2016-06-142-18/+0
| | | | | | | | | The sys_mmap/sys_mmap2 weirdness has been cleaned up in lss now and there is only one API now for everyone -- sys_mmap. R=mseaborn@chromium.org Review URL: https://codereview.chromium.org/2065493006 .
* Dump INFO CODE_ID containing Build ID in Linux dump_symsTed Mielczarek2016-06-109-34/+125
| | | | | | | | | | | | | I'd like to have the Build ID available for our symbol server uploading, and this will make it easy. Most of this change is me rewriting dump_symbols_unittest to be typed tests so I could add a new test there. R=mark@chromium.org BUG= Review URL: https://codereview.chromium.org/2052263002 .
* Fix a trivial parsing bug caught by static analysisNicholas Nethercote2016-06-101-1/+1
| | | | R=ted
* Update symbol file documentation links.Ralph Giles2016-06-103-3/+3
| | | | | | | These locations have changed since the move from Google Code. R=ted.mielczarek@gmail.com BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1275630
* linux/android: add SIGTRAP to the list of signals handled by the clientPrimiano Tucci2016-06-081-1/+1
| | | | | | | | | | | | | __builtin_trap() causes a SIGTRAP on arm64 (at least with GCC 4.9). SIGTRAP is not handled by breakpad, causing crashes induced by __builtin_trap() to be missed. Note that on x86 and arm, instead, __builtin_trap() raises a SIGILL, which is already handled by breakapd. BUG=chromium:614865 R=vapier@chromium.org Review URL: https://codereview.chromium.org/2042853002 .
* [Android] Roll back to r10e.Primiano Tucci2016-06-061-5/+21
| | | | | | | | BUG=599327 R=primiano@chromium.org TBR=mark@chromium.org Review URL: https://codereview.chromium.org/2042873003 .
* [Android] Revert x86 workaround changes for NDK r11c.Primiano Tucci2016-06-061-0/+11
| | | | | | | | BUG=599327 R=primiano@chromium.org TBR=mark@chromium.org Review URL: https://codereview.chromium.org/2035343002 .
* Adding support for overlapping ranges to RangeMap.Ivan Penkov2016-06-0510-89/+531
| | | | | | | | | | When enabled, adding of a new range that overlaps with an existing one can be a successful operation. The range which ends at the higher address will be shrunk down by moving its start position to a higher address so that it does not overlap anymore. This change is required to fix http://crbug/611824. The actual fix will come in a separate CL. R=mmandlis@chromium.org Review URL: https://codereview.chromium.org/2029953003 .
* [Android] Update breakpad to NDK r11c.Primiano Tucci2016-06-021-31/+4
| | | | | | | BUG=599327 R=mark@chromium.org, primiano@chromium.org Review URL: https://codereview.chromium.org/2025923003 .
* fix signed warning errors in unittestsMike Frysinger2016-05-262-13/+13
| | | | | | | | | | | | | | | | | | | | | | | A bunch of gtest assert statements fail due to signed warnings as unadorned constants are treated as signed integers. Mark them all unsigned to avoid that. One example (focus on the "[with ...]" blocks that show the types): In file included from src/breakpad_googletest_includes.h:33:0, from src/common/memory_unittest.cc:30: src/testing/gtest/include/gtest/gtest.h: In instantiation of 'testing::AssertionResult testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const T2&) [with T1 = int; T2 = long unsigned int]': src/testing/gtest/include/gtest/gtest.h:1524:23: required from 'static testing::AssertionResult testing::internal::EqHelper<true>::Compare(const char*, const char*, const T1&, const T2&, typename testing::internal::EnableIf<(! testing::internal::is_pointer<T2>::value)>::type*) [with T1 = int; T2 = long unsigned int; typename testing::internal::EnableIf<(! testing::internal::is_pointer<T2>::value)>::type = void]' src/common/memory_unittest.cc:41:246: required from here src/testing/gtest/include/gtest/gtest.h:1448:16: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] if (expected == actual) { ^ cc1plus: some warnings being treated as errors Makefile:5180: recipe for target 'src/common/src_client_linux_linux_client_unittest_shlib-memory_unittest.o' failed make[2]: *** [src/common/src_client_linux_linux_client_unittest_shlib-memory_unittest.o] Error 1 R=ted.mielczarek@gmail.com Review URL: https://codereview.chromium.org/2013893003 .
* elf_reader: drop unused zlib includeMike Frysinger2016-05-251-1/+3
| | | | | | | | | This breaks building for targets that don't include zlib. BUG=chromium:604440 R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/2010803003 .
* [MIPS] Rename variable mips to mips32Veljko Mihailovic2016-05-252-6/+6
| | | | | | | | | | | | Renaming variable mips to mips32 since mips is already defined by the toolchain. BUG=Compile error in Chromium R=mark@chromium.org Review URL: https://codereview.chromium.org/2006393004 . Patch from Veljko Mihailovic <veljko.mihailovic@imgtec.com>.
* Fixing an unused-variable warning in microdump_writer.ccIvan Penkov2016-05-241-1/+0
| | | | | | | BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=699 R=mark@chromium.org, primiano@chromium.org Review URL: https://codereview.chromium.org/2006333002 .
* Fix stack collection with size limitLars Volker2016-05-241-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | src/client/linux/minidump_writer/minidump_writer.cc:273 obtains the stack info by calling GetStackInfo(). That method will return the stack base address, aligned to the bottom of the memory page that 'stack_pointer' is in. After that it will cap the size of the memory area to be copied into the minidump to 'max_stack_len', starting from the base address, if the caller requested so. This will be the case when collecting reduced stacks, as introduced by this change: https://breakpad.appspot.com/487002/ In such cases the caller will request 2048 bytes of memory. However GetStackInfo() will have aligned the base address to the page boundary, by default 4096 bytes. If the stack, which grows towards the base address from the top ends before the 2048 bytes of the first block, then we will not collect any useful part of the stack. As a fix we skip chunks of 'max_stack_len' bytes starting from the base address until the stack_pointer is actually contained in the chunk, which we will add to the minidump file. BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=695 R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1959643004 . Patch from Lars Volker <lv@cloudera.com>.
* Functions only called by DumpFreeSpace need to be conditionally compiled.Tobias Sargeant2016-05-231-0/+6
| | | | | | | BUG=525938 R=mark@chromium.org Review URL: https://codereview.chromium.org/2008553002 .
* Add statistics about free space to microdump format.Primiano Tucci2016-05-231-2/+141
| | | | | | | | | | | | When a crash occurs as a result of an allocation failure, it is useful to know approximately what regions of the virtual address space remain available, so that we know whether the crash should be attributed to memory fragmentation, or some other cause. BUG=525938 R=primiano@chromium.org Review URL: https://codereview.chromium.org/1796803003 .
* use another elf.h inside the package for common/dwarf/elf_readerYunlian Jiang2016-05-181-1/+1
| | | | | | | | | | | | | | We tried to use common/android/include/elf.h, however it contains '#include-next elf.h' so it still breaks MAC build. So we use third_party/musl/include/elf.h instead. BUG=none TEST=make; make test passes. There is no '#include-next elf.h' in the new elf.h R=michaelbai@chromium.org Review URL: https://codereview.chromium.org/1994633003 .
* Use elf.h inside the package.Yunlian Jiang2016-05-181-1/+1
| | | | | | | | | | | | | MAC does not have elf.h, so use the elf.h inside the package instead of the one in the system. One failure example is https://codereview.chromium.org/1978803003/ TEST=make; make check BUG= R=michaelbai@chromium.org Review URL: https://codereview.chromium.org/1984713002 .
* Don't let PDBSourceLineWriter::GetSymbolFunctionName return empty function namesTed Mielczarek2016-05-161-0/+10
| | | | | | | | | | | | | | It's possible for `IDiaSymbol::get_name` to return S_OK and provide and empty string. I haven't figured out the exact root cause yet (the symbols in question are coming from the Rust standard library), but FUNC lines with missing function names break the processor and so we should never do it. This change makes it output "<name omitted>" which matches the behavior of the DWARF dumping code. R=mark@chromium.org BUG=https://bugzilla.mozilla.org/show_bug.cgi?id=1272278 Review URL: https://codereview.chromium.org/1985643004 .
* Revert "Write adjusted range back to module"Tao Bai2016-05-132-13/+0
| | | | | | | | | | | | | This is no right fix, we shouldn't allow module overlap. This reverts commit 4f417c8c0ffceb6c2516c6ef00cd91ca5746d852. BUG=606972 R=mark@chromium.org Review URL: https://codereview.chromium.org/1976683004 . Patch from Tao Bai <michaelbai@chromium.org>.
* Replaced glibc version of elf.h with musl version of elf.h.Dave MacLachlan2016-05-1213-4477/+3032
| | | | | | | | | Updated dump_syms xcode project and ran tests. BUG= R=vapier@chromium.org Review URL: https://codereview.chromium.org/1973113002 .
* Fixes up dump_syms build on OS X so it works with ELF.Dave MacLachlan2016-05-129-13/+4500
| | | | | | | | | | | | | | | Adds elf.h header from glibc. Updates dwarf2reader.cc so it isn't comparing a unique_ptr against NULL. Moves from MacOS10.5 SDK to latest SDK for Xcode project. Moves from using gcc to clang for dump_syms tests. Disables warning about 'Missing Field In Structure Initializers' to temporarily work around https://bugs.chromium.org/p/google-breakpad/issues/detail?id=697. With this patch all tests form dump_syms pass again using Xcode 7.3 on Mac OS X 10.11. BUG= https://bugs.chromium.org/p/google-breakpad/issues/detail?id=696, https://bugs.chromium.org/p/google-breakpad/issues/detail?id=697 R=mark@chromium.org Review URL: https://codereview.chromium.org/1970903002 .
* Update to handle dsym files that end with a header.Dave MacLachlan2016-05-111-1/+3
| | | | | | | | | | dsym files generated by Xcode for swift (Xcode 7.3) end with a header, and the code did not handle that case. BUG=https://bugs.chromium.org/p/google-breakpad/issues/detail?id=689 R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1971793002 .
* breakpad: fix unittest errorsYunlian Jiang2016-05-042-6/+2
| | | | | | | | | | | This fixes the unittest error caused by https://codereview.chromium.org/1884283002/ TEST=unittest passes on falco board in ChromeOS. BUG= R=vapier@chromium.org Review URL: https://codereview.chromium.org/1952083002 .
* Add debug fission support.Yunlian Jiang2016-05-0410-105/+2183
| | | | | | | | | | | | | | | | | | | | | This added debug fission support. It tries to find the dwp file from the debug dir /usr/lib/debug/*/debug and read symbols from them. Most of this patch comes from https://critique.corp.google.com/#review/52048295 and some fixes after that. The elf_reader.cc comes from TOT google code. I just removed some google dependency. Current problems from this patch 1: Some type mismatch: from uint8_t * to char *. 2: Some hack to find the .dwp file. (replace .debug with .dwp) BUG=chromium:604440 R=dehao@google.com, ivanpe@chromium.org Review URL: https://codereview.chromium.org/1884283002 .
* macho: fix printf type mismatchesMike Frysinger2016-05-041-3/+3
| | | | | | | | | The %ld expects a long signed integer, but we're passing in a size_t. Use %zu which is an unsigned size_t type. R=ted.mielczarek@gmail.com Review URL: https://codereview.chromium.org/1951603002 .
* 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 .
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-19 02:24:12 +0000