aboutsummaryrefslogtreecommitdiff
path: root/src/client/linux/minidump_writer
Commit message (Collapse)AuthorAgeFilesLines
* Fix minidump on ChromeOSYunlian Jiang2017-12-201-8/+25
| | | | | | | | | | | | | Chrome somehow changed the memory mapping with hugepage enabled. This makes the hack in CrOSPostProcessMappings more general. BUG=chromium:793452 TEST=with this patch on Chromium, minidump_dump *dmp shows the right information on chrome Change-Id: Iff58bf1a712a6e66cbd2d813422db7549a3080a5 Reviewed-on: https://chromium-review.googlesource.com/837963 Reviewed-by: Mark Mentovai <mark@chromium.org>
* Move main executable handling out of procmaps parser loop.Peter Collingbourne2017-10-171-19/+21
| | | | | | | | | | | | | | | | | | | | | | | | If the mapping for the main executable needed to be merged (for example, if it was linked with lld and therefore contains an r mapping followed by an r/x mapping), we would never reach the code that makes it the first module. Handle that situation by moving that code into a separate loop. This fixes an issue where breakpad_unittests fails on Android devices when linked with lld. It appears that the glibc dynamic loader happens to always load executables (or at least the executables that we create) at a lower address than DSOs, so we never hit this bug on desktop Linux. Testing: "make check" with both gold and lld as linker. Also breakpad_unittests when patched into Chromium on Linux (lld) and Android (gold and lld). Bug: chromium:469376 Change-Id: I6329e4afd2f1bf44c25a6c3e684495e21dba83a6 Reviewed-on: https://chromium-review.googlesource.com/722286 Reviewed-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Mark Mentovai <mark@chromium.org>
* Rename src/common/memory.h to memory_allocator.h.Ted Mielczarek2017-10-172-2/+2
| | | | | | | | | | | | memory.h shadows a system header which normally isn't a problem because of the include paths in Breakpad, but the Firefox build system winds up with src/common in the include path so we've had a workaround for this for years. Renaming the file lets us get rid of that workaround and shouldn't hurt anything. Change-Id: I3b7c4239dc77f3b2b7cf2b572a0cad88cd7e8522 Reviewed-on: https://chromium-review.googlesource.com/723261 Reviewed-by: Mark Mentovai <mark@chromium.org>
* Replace remaining references to 'struct ucontext' with 'ucontext_t'Mark Mentovai2017-09-201-1/+1
| | | | | | | | | | | | | | | | | This relands https://chromium.googlesource.com/breakpad/breakpad/src/+/e3035bc406cee8a4d765e59ad46eb828705f17f4, which was accidentally committed to breakpad/breakpad/src, the read-only mirror of src in breakpad/breakpad. (Well, it should have been read-only.) See https://crbug.com/766164. This fixes issues with glibc-2.26. See https://bugs.gentoo.org/show_bug.cgi?id=628782 , https://sourceware.org/git/?p=glibc.git;h=251287734e89a52da3db682a8241eb6bccc050c9 , and https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html for context. Change-Id: Id66f474d636dd2afa450bab925c5514a800fdd6f Reviewed-on: https://chromium-review.googlesource.com/674304 Reviewed-by: Mark Mentovai <mark@chromium.org>
* Add crash reason and address to microdumps.Tobias Sargeant2017-08-142-0/+73
| | | | | | | | | | | | This will allow us to provide the right information for webview renderer crashes. At the moment the crash information for the browser process is captured (from the debuggerd output) instead. BUG=754715 Change-Id: I409546311b6e38fe1cf804097c18d7bb2a015d83 Reviewed-on: https://chromium-review.googlesource.com/612381 Reviewed-by: Robert Sesek <rsesek@chromium.org>
* Merge exec and non-exec segments while merging executable bit.Peter Collingbourne2017-05-261-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bfd and gold linkers create segments like this: r/x, r/w where the r/x segment covers the start of the ELF file. lld's segments look like this: r, r/x, r/w where the r segment covers the start of the ELF file. So we cannot rely on the location of the r/x to tell where the start of the ELF is. But we can still rely on the r and r/x mappings being adjacent. So what we do is when we see an r segment followed by an r/x, merge the r into the r/x and claim that it is executable. This way, the minidump writer will continue to see a single executable segment covering the entire executable. Testing: "make check" passes when breakpad is compiled with lld compiled from trunk (requires bug fix from LLVM r303689). Also patched change into chromium and tested these builds: $ cat args.gn is_chrome_branded = true is_debug = false is_official_build = true use_lld = true allow_posix_link_time_opt = false is_cfi = false $ cat args.gn target_os = "android" target_cpu = "arm" is_debug = false is_official_build = true is_chrome_branded = true With both builds breakpad_unittests passes and chrome/chrome_modern_public_apk create good minidumps after navigating to chrome://inducebrowsercrashforrealz (checked that minidump contains stack trace entry for content::HandleDebugURL). Bug: chromium:716484 Change-Id: Ib6ed3a8420b83acf4a5962843930fb006734cb95 Reviewed-on: https://chromium-review.googlesource.com/513610 Reviewed-by: Primiano Tucci <primiano@chromium.org>
* Don't attempt to use PTRACE_GETREGS if it isn't defined.John Budorick2017-05-251-1/+5
| | | | | | | | | | | Follow up to https://chromium-review.googlesource.com/c/484479/, which does not compile on arm64. Bug: chromium:725754 Change-Id: Iaa6fbc332564909a10e2602a1026c14fb25625f4 Reviewed-on: https://chromium-review.googlesource.com/515044 Reviewed-by: Mark Mentovai <mark@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org>
* Simplify ELF parser code.Peter Collingbourne2017-05-251-5/+4
| | | | | | | | | | | | | The layout of Elf32_Nhdr and Elf64_Nhdr is the same, so remove templating and code that extracts the elfclass from the ELF file. Testing: "make check" and breakpad_unittests when patched into chromium. Bug: chromium:716484 Change-Id: I41442cfff48afc6ae1a5b604d22b67550a910376 Reviewed-on: https://chromium-review.googlesource.com/514450 Reviewed-by: Mike Frysinger <vapier@chromium.org>
* Use __NR_exit_group in MinidumpWriterTest.MinidumpStacksSkippedIfRequested.John Budorick2017-05-241-10/+24
| | | | | | | | | Also adds waits for all child processes spawned in MinidumpWriterTest. Bug: 725754 Change-Id: I3248925993dede2c113ab1989b322a9d9c8f24bd Reviewed-on: https://chromium-review.googlesource.com/513480 Reviewed-by: Mark Mentovai <mark@chromium.org>
* Fixing breakpad on old linux kernelAndrew Ermakovich2017-04-212-29/+53
| | | | | | | | | | Try to read the trace's registers by PTRACE_GETREGS if kernel doesn't support PTRACE_GETREGSET. Bug: Change-Id: I881f3a868789747ca217f22a93370c6914881f9a Reviewed-on: https://chromium-review.googlesource.com/484479 Reviewed-by: Mike Frysinger <vapier@chromium.org>
* Treat the process stack as the top of memory for free space histograms.Tobias Sargeant2017-03-291-0/+7
| | | | | | | | | | | | | Because we can't determine the top of userspace mappable memory directly, we rely on the fact that the process stack is allocated at the top of the address space (minus some randomization). Anything after that should not count as free space. BUG=695382 Change-Id: I68453aac9732c2bd4b87236b234518068dec6640 Reviewed-on: https://chromium-review.googlesource.com/446100 Reviewed-by: Primiano Tucci <primiano@chromium.org>
* Fix ASSERT_EQUAL that should have been ASSERT_EQ.Tobias Sargeant2017-03-241-1/+1
| | | | | | | | BUG=703599 Change-Id: I5623705edc41644495aa4f2389056d255e22da8e Reviewed-on: https://chromium-review.googlesource.com/459617 Reviewed-by: Primiano Tucci <primiano@chromium.org>
* Don't generate minidump if crash thread doesn't ref principal mapping.Tobias Sargeant2017-03-232-13/+105
| | | | | | | | | | | | | If the crashing thread doesn't reference the principal mapping we can assume that not only is that thread uninteresting from a debugging perspective, the whole crash is uninteresting. In that case we should not generate a minidump at all. BUG=703599 Change-Id: Ia25bbb8adb79d04dcaf3992c3d2474f3b9b1f796 Reviewed-on: https://chromium-review.googlesource.com/457338 Reviewed-by: Robert Sesek <rsesek@chromium.org>
* [MIPS] Get (ptrace) value of $pc for a threadGordana Cmiljanovic2017-03-221-0/+2
| | | | | | | | | This change is fixing LinuxPtraceDumperTest.SanitizeStackCopy test case. Change-Id: I1eb3becfd4b3660bc5529b5d2a5e35db0b6eb6e0 Reviewed-on: https://chromium-review.googlesource.com/458277 Reviewed-by: Mark Mentovai <mark@chromium.org>
* Improve stack sanitization unittests.Tobias Sargeant2017-02-242-47/+73
| | | | | | | | | | | | Rather than relying on the process stack having all the things that should/shouldn't be sanitized, create synthetic stacks to test all of the important cases. BUG=664460 Change-Id: I959266390e94d6fb83ca8ef11ac19fac89e68c31 Reviewed-on: https://chromium-review.googlesource.com/446108 Reviewed-by: Robert Sesek <rsesek@chromium.org>
* Make stack sanitization elide pointers to non-executable mappings.Tobias Sargeant2017-02-231-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | The address space of every Android Java process is approximately 50% mapped, which means that sanitization tends to be ineffective because most string fragments are plausibly pointers into some mapping. For example, the zygote on 32 bit devices has the following mappings made by dalvik and this covers all 4 byte strings starting with a character between 0x13 and 0x52 (which includes all uppercase characters up to and including 'R'). 12c00000-12d16000 12d16000-32c00000 32c00000-32c01000 32c01000-52c00000 In order to perform stack unwinding we only need pointers into the stack of the thread in question, and pointers to executable mappings. If we reduce the set of considered mappings to those mappings alone, then only ~2% of the address space is left unelided. BUG=664460 Change-Id: I1cc27821659acfb91d658f42a83a24c176505a88 Reviewed-on: https://chromium-review.googlesource.com/446500 Reviewed-by: Robert Sesek <rsesek@chromium.org>
* Use the correct PC when determining whether to skip storing a stack.Tobias Sargeant2017-02-231-5/+7
| | | | | | | | | | | | This addresses a bug in commit 049a1532 that meant that the PC of the crashing thread was always used to determine whether to include a stack, instead of using the PC of the thread in question. BUG=664460 Change-Id: Idcbd5db751e5c00941a1be28607389961c0c75d7 Reviewed-on: https://chromium-review.googlesource.com/446499 Reviewed-by: Robert Sesek <rsesek@chromium.org>
* Address post-submit review comments related to CL #430050Tobias Sargeant2017-02-072-6/+13
| | | | | | | | | | See: https://chromium-review.googlesource.com/c/430050/ BUG=664460 Change-Id: I3cbfbd5b00725bd501f06427eebd976267c4f617 Reviewed-on: https://chromium-review.googlesource.com/438444 Reviewed-by: Primiano Tucci <primiano@chromium.org>
* Remove debugging fprintf in unittest code that prevents rolling breakpadTobias Sargeant2017-02-061-1/+0
| | | | | | | | BUG=664460 Change-Id: I40d8567c659e97415db65cb308c0d39391c44353 Reviewed-on: https://chromium-review.googlesource.com/438364 Reviewed-by: Primiano Tucci <primiano@chromium.org>
* Wire up stack sanitization and skipping to WriteMinidumpTobias Sargeant2017-02-033-33/+214
| | | | | | | | | | | | This makes the parameters stored in the MinidumpDescriptor structure functional for minidumps, analogously to how they are applied to microdumps. BUG=664460 Change-Id: I7578e7a1638cea8f0445b18d4bbdaf5e0a32d808 Reviewed-on: https://chromium-review.googlesource.com/435380 Reviewed-by: Robert Sesek <rsesek@chromium.org>
* Sanitize dumped stacks to remove data that may be identifiable.Tobias Sargeant2017-01-313-54/+245
| | | | | | | | | | | | | | | In order to sanitize the stack contents we erase any pointer-aligned word that could not be interpreted as a pointer into one of the processes' memory mappings, or a small integer (+/-4096). This still retains enough information to unwind stack frames, and also to recover some register values. BUG=682278 Change-Id: I541a13b2e92a9d1aea2c06a50bd769a9e25601d3 Reviewed-on: https://chromium-review.googlesource.com/430050 Reviewed-by: Robert Sesek <rsesek@chromium.org>
* Add API to skip dump if crashing thread doesn't reference a given moduleTobias Sargeant2017-01-183-1/+59
| | | | | | | | | | | | | | | | | | | | | | | | This CL makes it possible to skip a dump if the crashing thread doesn't have any pointers to a given module. The concrete use case is WebView where we would like to skip generating microdump output when webview is unreferenced by the stack and thus cannot be responsible for the crash in a way that would be debuggable. The range of interesting addresses is chosen by examining the process mappings to find the one that contains a pointer that is known to be in the right shared object (i.e. an appropriately chosen function pointer) passed from the client. If the extracted stack does not contain a pointer in this range, then we do not generate a microdump. If the stack extraction fails, we still generate a microdump (without a stack). BUG=664460 Change-Id: If19406a13168264f7751245fc39591bd6cdbf5df Reviewed-on: https://chromium-review.googlesource.com/419476 Reviewed-by: Robert Sesek <rsesek@chromium.org> Reviewed-by: Primiano Tucci <primiano@chromium.org>
* Recover memory mappings before writing dump on ChromeOSTing-Yuan (Leo) Huang2016-07-181-0/+172
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Linux, breakpad relies on /proc/[pid]/maps to associate symbols from addresses. ChromeOS' hugepage implementation replaces some segments with anonymous private pages, which is a restriction of current implementation in Linux kernel at the time of writing. Thus, breakpad can no longer symbolize addresses from those text segments replaced by hugepages. This patch tries to recover the mappings. Because hugepages are always inserted in between some .text sections, it tries to infer the names and offsets of the segments, by looking at segments immediately precede and succeed them. For example, a text segment before hugepage optimization 02001000-03002000 r-xp /opt/google/chrome/chrome can be broken into 02001000-02200000 r-xp /opt/google/chrome/chrome 02200000-03000000 r-xp 03000000-03002000 r-xp /opt/google/chrome/chrome BUG=crbug.com/628040 R=mark@chromium.org Review URL: https://codereview.chromium.org/2161713002 . Patch from Ting-Yuan (Leo) Huang <laszio@chromium.org>.
* Server-side workaround to handle overlapping modules.Ivan Penkov2016-06-201-0/+2
| | | | | | | | | | | | | | 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 .
* 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>.
* 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 .
* Switch the Linux minidump writer to use MDCVInfoELF for CV data.Ted Mielczarek2016-04-055-74/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 .
* 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-076-34/+57
| | | | | | | | | | | 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/
* 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 .
* [mips64] Support for mips n64Mike Frysinger2016-02-061-0/+6
| | | | | | | | | | 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 .
* Fix compilation of breakpad on Linux.Sylvain Defresne2016-01-081-2/+2
| | | | | | | | | Fix some copy/paste errors from commit 41440eaa. BUG=None R=thestig@chromium.org Review URL: https://codereview.chromium.org/1564293002 .
* Use range-based for loops in linux/minidump_writer/minidump_writer.cc.Lei Zhang2016-01-071-45/+32
| | | | | | | | Also fix lint errors. R=mark@chromium.org Review URL: https://codereview.chromium.org/1562273002 .
* Avoid comparing size_t to be < 0 on AArch64.Lei Zhang2016-01-061-2/+2
| | | | | | | | | | | | cpu_features_entries is empty on AArch64 and causes tautological-compare warning when compiling with Clang. A=dskiba@google.com Original Review: https://codereview.chromium.org/1562223002/ BUG=chromium:539781 Review URL: https://codereview.chromium.org/1566893002 .
* Remove obsolete seccomp_unwinder for legacy (pre-BPF) sandboxprimiano@chromium.org2015-08-181-6/+0
| | | | | | | | | | | | | | | | | | | | | The PopSeccompStackFrame was introduced to deal with stack frames originated in the legacy seccomp sandbox. The only user of that sandbox was Google Chrome, but the legacy sandbox has been deprecated in 2013 (crrev.com/1290643003) in favor of the new bpf sandbox. Removing this dead code as it has some small bound checking bug which causes occasional crashes in WebView (which are totally unrelated to the sandbox). Note: this will require a corresponding change in the chromium GYP/GN build files to roll. BUG=665,chromium:477444 R=jln@chromium.org, mark@chromium.org, torne@chromium.org Review URL: https://codereview.chromium.org/1299593003 . git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1492 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix breakpad for arm on arm64cjhopman@chromium.org2015-08-051-0/+6
| | | | | | | | | | | | On arm64 devices, GETFPREGS fails with errno==EIO. Ignore those failures on Android arm builds. BUG=508324 R=thestig@chromium.org Review URL: https://codereview.chromium.org/1268023003 . git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1479 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Adjust breakpad module size to match adjusted start_addr.rmcilroy@chromium.org2015-06-301-4/+9
| | | | | | | | | | | | | | | | | | When changing a module's start_addr to account for Android packed relocations, also adjust its size field so that the apparent module end addr calculated by the breakpad processor does not alter. Ensures that the mapping entry from a packed library is consistent with that which an unpacked one would produce. BUG=499747 R=primiano@chromium.org, rmcilroy@chromium.org Review URL: https://codereview.chromium.org/1211863002. Patch from Simon Baldwin <simonb@chromium.org>. git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1465 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Update breakpad for Android packed relocations.rmcilroy@chromium.org2015-06-193-1/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [MIPS]: Use mcontext_t structure for MIPSrmcilroy@chromium.org2015-04-213-27/+40
| | | | | | | | | | | | | | This change removes user_regs_struct and user_fpregs_struct structures for mips and uses mcontext_t instead. R=fdegans@chromium.org, mark@chromium.org, rmcilroy@chromium.org Review URL: https://breakpad.appspot.com/3744002 Patch from Gordana Cmiljanovic <Gordana.Cmiljanovic@imgtec.com>. git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1452 4c0a9323-5329-0410-9bdc-e9ce6186880e
* MIPS64: Initial MIPS64 related change.mark@chromium.org2015-04-152-3/+13
| | | | | | | | | | | With this change Breakpad can be compiled for MIPS64, but it is not yet functional. Patch by Gordana Cmiljanovic <Gordana.Cmiljanovic@imgtec.com> Review URL: https://breakpad.appspot.com/6824002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1446 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix compilation with gcc --std=c++11ted.mielczarek@gmail.com2015-03-241-1/+1
| | | | | | | | | Patch by Jon Turney <jon.turney.1111@gmail.com> R=ted at https://breakpad.appspot.com/7824002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1435 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Handle failures of copying process data from a core file.benchan@chromium.org2015-02-026-16/+31
| | | | | | | | | | | | | | | | | | | | | | | | | When LinuxCoreDumper fails to copy process data from a core file, it fills the return buffer with a repeated sequence of a special marker. However, MinidumpWriter doesn't know about that and may incorrectly interpret the data. In many cases, MinidumpWriter simply copies the gibberish data to the minidump, which isn't too bad. However, the gibberish data may cause MinidumpWriter to behave badly in some other cases. For example, when MinidumpWriter tries to iterate through the linked list of all loaded DSOs via the r_map field of a r_debug struct, if the linked list is filed with the special marker, the code keeps iterating through the same address. This CL addresses the issue by having LinuxCoreDumper::CopyFromProcess() returns a Boolean value to indicate if the expected data is found from the core file. MinidumpWriter can then decide how to handle that. BUG=chromium:453484 TEST=Run core2md with the test data attached to chromium:453484. R=mark@chromium.org Review URL: https://breakpad.appspot.com/4724002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1420 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Stop calling memmove when unnecessaryhashimoto@chromium.org2015-01-271-2/+4
| | | | | | | | | BUG=chromium:450137 R=mark@chromium.org git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1416 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Remove pointers from serialized file formatmdempsky@chromium.org2014-12-111-5/+9
| | | | | | | | | BUG=breakpad:621 R=thestig@chromium.org Review URL: https://breakpad.appspot.com/1764002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1410 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Introduce microdump writer class.primiano@chromium.org2014-10-281-8/+0
| | | | | | | | | | | | | | | | | | | Microdumps are a very lightweight variant of minidumps. They are meant to dump a minimal crash report on the system log (logcat on Android), containing only the state of the crashing thread. This is to deal with cases where the user has opted out from crash uploading but we still want to generate meaningful information on the device to pull a stacktrace for development purposes. Conversely to conventional stack traces (e.g. the one generated by Android's debuggerd or Chromium's base::stacktrace) microdumps do NOT require unwind tables to be present in the target binary. This allows to save precious binary size (~1.5 MB for Chrome on Arm, ~10 MB on arm64). More information and design doc on crbug.com/410294 BUG=chromium:410294 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1398 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Refactor .so name detection logic in minidump/linux_dumper.primiano@chromium.org2014-10-173-54/+70
| | | | | | | | | | | | | | | | This is a refactoring of the logic which determines the module name and path for a given MappingInfo in minidump_writer.cc. Such logic, which will be soon shared also with the upcoming microdump_writer.cc, is simply being moved to linux_dumper.cc, extracting a GetMappingEffectiveNameAndPath method. No behavioral change is intended. BUG=chromium:410294 R=thestig@chromium.org Review URL: https://breakpad.appspot.com/7734002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1392 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Microdumps: refactor out common parts of minidump_writer.ccprimiano@chromium.org2014-10-012-619/+17
| | | | | | | | | | | | | | | | | | | | This change is a pure refactoring of the common bits of minidump_writer.cc that will be shared soon with the upcoming microdump_writer.cc. In particular, this CL is extracting the following classes: - ThreadInfo: handles the state of the threads in the crashing process. - RawContextCPU: typedef for arch-specific CPU context structure. - UContextReader: Fills out a dump RawContextCPU structure from the ucontext struct provided by the kernel (arch-dependent). - SeccompUnwinder: cleans out the stack frames of the Seccomp sandbox on the supported architectures. - MappingInfo: handles information about mappings BUG=chromium:410294 R=mmandlis@chromium.org Review URL: https://breakpad.appspot.com/4684002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1388 4c0a9323-5329-0410-9bdc-e9ce6186880e
* IWYU in minidump_writer.cc to fix building with libc++ after r1385.thestig@chromium.org2014-09-241-0/+1
| | | | | | | | R=ivanpe@chromium.org Review URL: https://breakpad.appspot.com/6744002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1386 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix clang compilation error introduced in r1380.rmcilroy@chromium.org2014-09-221-1/+1
| | | | | | | | | | | | | | | | Fixes: .../linux_dumper.cc:308:25: error: address of array 'module->name' will always evaluate to 'true' [-Werror,-Wpointer-bool-conversion] module->name && module->name[0] == '/' && ~~~~~~~~^~~~ BUG=chromium:394703 R=rmcilroy@chromium.org Review URL: https://breakpad.appspot.com/5724002 Patch from Simon Baldwin <simonb@chromium.org>. git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1384 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Extend mapping merge to include reserved but unused mappings.rmcilroy@chromium.org2014-09-191-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 R=rmcilroy@chromium.org, thestig@chromium.org Review URL: https://breakpad.appspot.com/7714003 Patch from Simon Baldwin <simonb@chromium.org>. git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1380 4c0a9323-5329-0410-9bdc-e9ce6186880e
generated by cgit v1.2.1 (git 2.18.0) at 2024-07-02 20:37:56 +0000