aboutsummaryrefslogtreecommitdiff
path: root/src
Commit message (Collapse)AuthorAgeFilesLines
...
* Set exception whitelist check as earlier check instead of last check.Liu.andrew.x@gmail.com2015-07-071-15/+15
| | | | | | | | | | | | | | | When I first added the exception whitelist, I meant to put the check before checking the location of the instruction pointer. (I didn't notice that it was after the other check until now.) The whitelist check is to quickly rule out minidumps, and if checking the instruction pointer provided any useful information, it would be pretty indicative that the exception causing the dump is interesting. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1211253009 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1469 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Use general instruction/stack pointer convenience method instead of manuallyLiu.andrew.x@gmail.com2015-06-307-33/+74
| | | | | | | | | | | | | | finding the instruction/stack pointer for exploitability rating. There was already a method that found the instruction pointer, so the files for exploitability ratings had repeated code. Also a method for finding the stack pointer is implemented in this CL. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1210943005 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1468 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Checking for benign exceptions that trigger a minidump.Liu.andrew.x@gmail.com2015-06-303-3/+62
| | | | | | | | | | | | | If the exception reponsible for the crash is benign, such as a floating point exception, we can rule out the possibility that the code is exploitable. This CL checks for such exceptions and marks the dump as not exploitable if such an exception is found. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1212383004 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1467 4c0a9323-5329-0410-9bdc-e9ce6186880e
* This CL adds support for ARM and ARM64 architectures when calculatingLiu.andrew.x@gmail.com2015-06-301-1/+8
| | | | | | | | | | | | | | exploitability ratings. The stackwalker will now grab the instruction pointers for ARM and ARM64 architectures, so checking exploitability on ARM and ARM64 will no longer return EXPLOITABILITY_ERR_PROCESSING. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1216063004 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1466 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
* Checking location of the instruction pointer to see if it isLiu.andrew.x@gmail.com2015-06-256-0/+71
| | | | | | | | | | | | | | | | in valid code for Linux exploitability rating. This CL adds to the Linux exploitability checker by verifying that the instruction pointer is in valid code. Verification is done by obtaining a memory mapping of the crash and checking if the instruction pointer lies in an executable region. If there is no memory mapping, the instruction pointer is checked to determine if it lies within a known module. R=ivanpe@chromium.org Review URL: https://codereview.chromium.org/1210493003 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1464 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Reconfigured options for sym_upload to not treat h and ? flags as invalid ↵ivanpe@chromium.org2015-06-221-0/+5
| | | | | | | | | | | | options. I'm submitting this on behalf of Andrew Liu. R=mmandlis@chromium.org Review URL: https://codereview.chromium.org/1196733004 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1462 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix signal propagation logic for Linux/Android exception handler.primiano@chromium.org2015-06-221-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current code is relying on info->si_pid to figure out whether the exception handler was triggered by a signal coming from the kernel (that will re-trigger until the cause that triggered the signal has been cleared) or from user-space e.g., kill -SIGNAL pid, which will NOT automatically re-trigger in the next signal handler in the chain. While the intentions are good (manually re-triggering user-space signals), the current implementation mistakenly looks at the si_pid field in siginfo_t, assuming that it is coming from the kernel if si_pid == 0. This is wrong. siginfo_t, in fact, is a union and si_pid is meaningful only for userspace signals. For signals originated by the kernel, instead, si_pid overlaps with si_addr (the faulting address). As a matter of facts, the current implementation is mistakenly re-triggering the signal using tgkill for most of the kernel-space signals (unless the fault address is exactly 0x0). This is not completelly correct for the case of SIGSEGV/SIGBUS. The next handler in the chain will stil see the signal, but the |siginfo| and the |context| arguments of the handler will be meaningless (retriggering a signal with tgkill doesn't preserve them). Therefore, if the next handler in the chain expects those arguments to be set, it will fail. Concretelly, this is causing problems to WebView. In some rare circumstances, the next handler in the chain is a user-space runtime which does SIGSEGV handling to implement speculative null pointer managed exceptions (see as an example http://www.mono-project.com/docs/advanced/runtime/docs/exception-handling/) The fix herein proposed consists in using the si_code (see SI_FROMUSER macros) to determine whether a signal is coming form the kernel (and therefore just re-establish the next signal handler) or from userspace (and use the tgkill logic). Repro case: This issue is visible in Chrome for Android with this simple repro case: - Add a non-null pointer dereference in the codebase: *((volatile int*)0xbeef) = 42 Without this change: the next handler (the libc trap) prints: F/libc ( 595): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x487 where 0x487 is actually the PID of the process (which is wrong). With this change: the next handler prints: F/libc ( 595): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xbeef which is the correct answer. BUG=chromium:481937 R=mark@chromium.org Review URL: https://breakpad.appspot.com/6844002. git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1461 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Use local variable for out parameter rather than direct use of ivarivanpe@chromium.org2015-06-201-2/+3
| | | | | | | | | | | | - Resolves spurious static analyzer warning about response_ being potentially leaked due to the retain in Xcode 6.3 and later. I'm submitting this on behalf of Brian Moore. R=qsr@chromium.org Review URL: https://codereview.chromium.org/1171693007 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1460 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Update breakpad for Android packed relocations.rmcilroy@chromium.org2015-06-195-2/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [microdump] Add build fingerprint and product info metadata.primiano@chromium.org2015-05-156-50/+163
| | | | | | | | | | | | | | | | This is to add build fingerprint and product name/version to microdumps. Conversely to what happens in the case of minidumps with MIME fields, due to the nature of minidumps, extra metadata cannot be reliably injected after the dump is completed. This CL adds the plumbing to inject two optional fields plus the corresponding tests. BUG=chromium:410294 R=thestig@chromium.org Review URL: https://codereview.chromium.org/1125153008 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1456 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix signal propagation logic for Linux/Android exception handler.primiano@chromium.org2015-04-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current code is relying on info->si_pid to figure out whether the exception handler was triggered by a signal coming from the kernel (that will re-trigger until the cause that triggered the signal has been cleared) or from user-space e.g., kill -SIGNAL pid, which will NOT automatically re-trigger in the next signal handler in the chain. While the intentions are good (manually re-triggering user-space signals), the current implementation mistakenly looks at the si_pid field in siginfo_t, assuming that it is coming from the kernel if si_pid == 0. This is wrong. siginfo_t, in fact, is a union and si_pid is meaningful only for userspace signals. For signals originated by the kernel, instead, si_pid overlaps with si_addr (the faulting address). As a matter of facts, the current implementation is mistakenly re-triggering the signal using tgkill for most of the kernel-space signals (unless the fault address is exactly 0x0). This is not completelly correct for the case of SIGSEGV/SIGBUS. The next handler in the chain will stil see the signal, but the |siginfo| and the |context| arguments of the handler will be meaningless (retriggering a signal with tgkill doesn't preserve them). Therefore, if the next handler in the chain expects those arguments to be set, it will fail. Concretelly, this is causing problems to WebView. In some rare circumstances, the next handler in the chain is a user-space runtime which does SIGSEGV handling to implement speculative null pointer managed exceptions (see as an example http://www.mono-project.com/docs/advanced/runtime/docs/exception-handling/) The fix herein proposed consists in using the si_code (see SI_FROMUSER macros) to determine whether a signal is coming form the kernel (and therefore just re-establish the next signal handler) or from userspace (and use the tgkill logic). Repro case: This issue is visible in Chrome for Android with this simple repro case: - Add a non-null pointer dereference in the codebase: *((volatile int*)0xbeef) = 42 Without this change: the next handler (the libc trap) prints: F/libc ( 595): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x487 where 0x487 is actually the PID of the process (which is wrong). With this change: the next handler prints: F/libc ( 595): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xbeef which is the correct answer. BUG=chromium:481937 R=mark@chromium.org Review URL: https://breakpad.appspot.com/6844002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1454 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Support object files larger than 2**32.erikchen@chromium.org2015-04-227-40/+189
| | | | | | | Reviewed at https://breakpad.appspot.com/7834002/#ps340001 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1453 4c0a9323-5329-0410-9bdc-e9ce6186880e
* [MIPS]: Use mcontext_t structure for MIPSrmcilroy@chromium.org2015-04-219-160/+134
| | | | | | | | | | | | | | 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
* Fix call to rt_sigactioncjhopman@chromium.org2015-04-151-4/+4
| | | | | | | | | | | Despite the fact that many places imply that sigaction and rt_sigaction are essentially the same, rt_sigaction's signature is actually different-- it takes the size of the kernel's sigset_t as an extra argument. BUG=473973 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1447 4c0a9323-5329-0410-9bdc-e9ce6186880e
* MIPS64: Initial MIPS64 related change.mark@chromium.org2015-04-1514-20/+156
| | | | | | | | | | | 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
* Use __NR_rt_sigaction instead of __NR_sigactionmark@chromium.org2015-04-131-1/+1
| | | | | | | | | | | __NR_sigaction is not defined on arm64/x64/etc (or rather, it's defined in unistd-32.h instead of unistd.h). Patch by Chris Hopman <cjhopman@chromium.org> Review URL: https://breakpad.appspot.com/10724002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1443 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Microdump processor: be more tolerant for different logcat formatsprimiano@chromium.org2015-04-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The current processor implementation is grepping for /google-breakpad( in the logcat lines, to filter out microdump lines, which by default look like this: W/google-breakpad( 3728): -----BEGIN BREAKPAD MICRODUMP----- Turns out that logcat format can vary, when passing optional arguments, and produce something like the following: 04-13 12:30:35.563 6531 6531 W google-breakpad: -----BEGIN ... In the latter case, the "/google-breakpad(" filter is too aggressive. This change is relaxing it, so it is compatible also with non-default logcat arguments. BUG=640 R=mmandlis@chromium.org Review URL: https://breakpad.appspot.com/2864002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1442 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add address and reason for IN_PAGE_ERROR.mark@chromium.org2015-04-105-3/+8661
| | | | | | | | | | | | | | ACCESS_VIOLATION and IN_PAGE_ERROR both specify read/write/dep flags and address. ACCESS_VIOLATION currently reports these, but IN_PAGE_ERROR does not. This change makes IN_PAGE_ERROR report this information as well, and also the additional NTSTATUS value for the underlying cause. Patch by bungeman@chromium.org Review URL: https://breakpad.appspot.com/1794002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1441 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Workaround Android sigaction bugmark@chromium.org2015-04-101-3/+21
| | | | | | | | | | | | | | | | | On Android L+, signal and sigaction symbols are provided by libsigchain that override the system's versions. There is a bug in these functions where they essentially ignore requests to install SIG_DFL. Workaround this issue by explicitly performing a syscall to __NR_rt_sigaction to install SIG_DFL on Android. BUG=473973 Patch by Chris Hopman <cjhopman@chromium.org> Review URL: https://breakpad.appspot.com/1804002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1438 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix compilation with gcc --std=c++11ted.mielczarek@gmail.com2015-03-246-18/+18
| | | | | | | | | 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
* Fix compatibility with Android NDK r10d.primiano@chromium.org2015-03-162-17/+20
| | | | | | | | | | | | | | | | This is a reland of the previous CL (r1433). r1433 did not achieve what intended and failed the x86_64 build of Chrome with NDK r10c. The workaround logic in this CL is identical to r1433, but the #define magic is applied in a more appropriate proper place this time. Turns out Breakpad already has an Android compatibility layer, which is common/android/include. Piggybacking the fix there. BUG=breakpad:642 R=fdegans@chromium.org, rmcilroy@chromium.org Review URL: https://breakpad.appspot.com/3794002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1434 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Make breakpad compatible with Android NDK r10d.primiano@chromium.org2015-03-102-5/+16
| | | | | | | | | | | | | | | | | | | | | r1397 did introduce a workaround to deal with a typo in sys/user.h in the Android NDK. The typo has been fixed in [1]. However, breakpad cannot just switch to the fixed version as this would require atomic rolls of Breakpad and NDK in chromium, which would make reverts hard to handle. This change introduces an inelegant yet functional hack which makes breakpad compatible with both versions of the NDK, with and without the typo. It can be reverted once Chrome has stably rolled to NDK r10d. [1] https://android.googlesource.com/platform/bionic/+/f485547b BUG=breakpad:642 R=fdegans@chromium.org, rmcilroy@chromium.org Review URL: https://breakpad.appspot.com/7814002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1433 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Microdump writer: stop using new/malloc in compromised contextprimiano@chromium.org2015-03-101-9/+13
| | | | | | | | | | | | | | | | A recent change in the client-side microdump write (r1404) ended up introducing a call to new() to instantiate the line buffer that microdump uses to dump its lines. new/malloc is a luxury we cannot afford in a compromised context. This change switches the line buffer to be backed by the dumper page allocator, which on Linux/Android ends up requesting pages via mmap. Also, the microdump write bails out without crashing if the page allocator failed (crash during severe OOM). BUG=640 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1432 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix Windows dump_syms x64 linkingted.mielczarek@gmail.com2015-03-061-2/+20
| | | | | | | | The dia_sdk GYP target points at the x86 diaguids.lib, it needs to point at the x64 one for x64 builds. R=mark at https://breakpad.appspot.com/9784002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1431 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Formatting tweak for https://breakpad.appspot.com/9774002, add more newlinested.mielczarek@gmail.com2015-02-271-4/+5
| | | | git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1430 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add stack contents output functionality to minidump_stackwalkhashimoto@chromium.org2015-02-274-14/+185
| | | | | | | | | | | | | | | | | This feature is enabled only when "-s" is provided as a commandline option. minidump_stackwalk.cc: - Add a new commandline option "-s" to output stack contents. - Instantiate Minidump object in PrintMinidumpProcess() to keep it alive longer so that accessing process_state.thread_memory_regions() in stackwalk_common.cc doesn't result in use-after-free. stackwalk_common.cc: - Add a new function PrintStackContents() to output stack contents. R=mark@chromium.org Review URL: https://breakpad.appspot.com/9774002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1429 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Update license on convert_UTF.* to the standard Unicode license.mark@chromium.org2015-02-252-32/+64
| | | | | | | | | BUG=google-breakpad:270 R=ted.mielczarek@gmail.com Review URL: https://breakpad.appspot.com/9764002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1428 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add option to Breakpad to consume INVALID_HANDLE_VALUE exceptions.wfh@chromium.org2015-02-222-0/+19
| | | | | | | | | BUG=chromium:452613 R=mark@chromium.org Review URL: https://breakpad.appspot.com/7794002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1427 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Cleanup Linux debug link file handling code.thestig@chromium.org2015-02-101-44/+74
| | | | | | | | | | | - Handle the case when the debug link points back to the object file. - Move some checks into a separate SanitizeDebugFile() function. BUG=636 Review URL: https://breakpad.appspot.com/3784002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1426 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix overflow error in breakpad for linuxmark@chromium.org2015-02-051-4/+4
| | | | | | | | | | | | | | | A computation in the stack unwind algorithm could cause an overflow if a base pointer read from crashed process is sufficiently close to top of address space. This causes a memory read that causes the dump thread to crash, resulting in a failure to generate crash dump. Check fixed to properly detect that this pointer is greater than actual memory range of current stack. Patch by Kyle Joswiak <kjoswiak@chromium.org> Review URL: https://breakpad.appspot.com/3754003/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1425 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add unit tests for overlapping functions and externs.thestig@chromium.org2015-02-041-0/+68
| | | | | | | | R=mark@chromium.org Review URL: https://breakpad.appspot.com/3774002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1424 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Handle ARM THUMB functions when removing duplicate PUBLIC entries.thestig@chromium.org2015-02-031-3/+18
| | | | | | | | | | | In ELF symtab/dynsym sections, THUMB function addresses have bit 0 set, whereas the DWARF function entries are not. R=mark@chromium.org Review URL: https://breakpad.appspot.com/7774002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1423 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Follow debug link correctlyhashimoto@chromium.org2015-02-032-50/+52
| | | | | | | | | | | | As thestig@chromium.org pointed out in https://breakpad.appspot.com/9684002, LoadSymbols() should return false if |read_gnu_debug_link| is false. BUG=chromium:453498 R=thestig@chromium.org Review URL: https://breakpad.appspot.com/2844002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1422 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Demangle symbol namehashimoto@chromium.org2015-02-032-1/+12
| | | | | | | | | | | | The spec says it should be demangled. https://code.google.com/p/google-breakpad/wiki/SymbolFiles BUG=chromium:453498 R=mark@chromium.org Review URL: https://breakpad.appspot.com/2854002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1421 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
* Replace uses of hash_map with unordered_mapted.mielczarek@gmail.com2015-02-021-6/+6
| | | | | | | | hash_map no longer exists in Visual C++ 2015. A=Brian Smith <brian@briansmith.org> R=ted at https://bugzilla.mozilla.org/show_bug.cgi?id=1119072 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1419 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Remove unneeded definitions of O_BINARYvapier@chromium.org2015-01-282-2/+0
| | | | | | | Review URL: https://breakpad.appspot.com/6684002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1418 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Remove unused variable 'kGUIDStringSize' in microdump_writer_unittest.benchan@chromium.org2015-01-281-4/+0
| | | | | | | | R=mark@chromium.org Review URL: https://breakpad.appspot.com/3754002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1417 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
* Fix some fragile code that is likely to cause future memory corruptionerikchen@chromium.org2015-01-278-58/+62
| | | | | | | | | | | | | | | | | | problems. - The ordering of keys in stl containers cannot change. Make the relevant members const to guarantee this assumption. - Add handling and logging for demangle errors. - Fix a potential double-delete bug if a function passed to AddFunction() is already present. BUG=chromium:449214 R=mark@chromium.org Review URL: https://breakpad.appspot.com/10704002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1415 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix a source of memory corruption.erikchen@chromium.org2015-01-261-7/+13
| | | | | | | | | | | This error was causing crashes in official Chrome Mac builds on 10.8.5 machines. BUG=chromium:449214 R=mark@chromium.org git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1414 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Fix the scope on the initialization of kMicrodumpOnConsole to match header.primiano@chromium.org2015-01-091-1/+2
| | | | | | | | | | | I whish I knew how this worked for months in chromium as it is clearly wrong. As reported by azarchs@ it is breaking the cygprofile instrumented build. BUG=chromium:410294 Review URL: https://breakpad.appspot.com/1784002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1413 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Modify minidump_stackwalk to be more tolerant of overlapping ranges.wfh@chromium.org2014-12-201-6/+20
| | | | | | | | | | | These ranges can be seen in some Android minidumps. BUG=chromium:439531 R=mark@chromium.org Review URL: https://breakpad.appspot.com/9744002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1412 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Add microdump files to project.jessicag.feedback@gmail.com2014-12-111-0/+6
| | | | git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1411 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Remove pointers from serialized file formatmdempsky@chromium.org2014-12-114-23/+108
| | | | | | | | | 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
* Breakpad: Fix build with new clang versions.mark@chromium.org2014-12-102-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gcc has a single exception setting for all languages. Saying -fno-exceptions in gcc disables exceptions and cleanups for cc files, but has no effect for mm files. In clang, -fno-exceptions only disables c++ exceptions, but keeps objective-c exceptions and cleanups enabled. http://llvm.org/viewvc/llvm-project?view=revision&revision=220714 changed __EXCEPTIONS to be defined for clang when cleanups are enabled, independent of if c++ exceptions are enabled. (This was necessary to have clang work with glibc which looks at __EXCEPTIONS to decide if cleanups are enabled.) Breakpad tried to use __EXCEPTIONS to figure out if c++ exceptions are enabled. In cc files, this works: -fno-exceptions will disable c++ exceptions and cleanups. But in mm files, -fno-exceptions will disable c++ exceptions and objective-c exceptions will still be enabled, and so cleanups must run and hence __EXCEPTIONS is defined. To make things work with both old and new compilers, do the try/catch hack in mm files either if __EXCEPTIONS is not defined (for old compilers) or if the compiler is clang and __has_feature(cxx_exceptions) isn't set (which will work for new clangs too, and which cleanly maps to if c++ exceptions are enabled). Patch by Nico Weber <thakis@chromium.org> Review URL: https://breakpad.appspot.com/1774002/ git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1409 4c0a9323-5329-0410-9bdc-e9ce6186880e
* dump_syms: Fix handling of DW_FORM_ref_addr to work with DWARF 4mseaborn@chromium.org2014-12-031-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, dump_syms did not handle DW_FORM_ref_addr if it appeared in DWARF 4 debugging info. Also fix a DW_FORM_ref_addr case so that it doesn't fall through to the next switch case when assertions are disabled and the DWARF version isn't recognised. The following steps will reproduce the problem when using LLVM 3.4: cat <<END >example1.c int main() { return 0; } END cat <<END >example2.c void foo(int x) {} END clang -emit-llvm -g -c example1.c -o example1.bc clang -emit-llvm -g -c example2.c -o example2.bc llvm-link-3.4 example1.bc example2.bc -o combined.bc clang combined.bc -o executable ./google-breakpad/build/src/tools/linux/dump_syms/dump_syms executable When using LLVM bitcode linking in this way, LLVM's backend generates partially-merged DWARF debugging info in which some of the references to the "int" type go via "DW_FORM_ref_addr". Since PNaCl uses LLVM bitcode linking, this dump_syms failure occurs with nexes produced by the PNaCl toolchain. BUG= https://code.google.com/p/chromium/issues/detail?id=416368 TEST= see above R=mark@chromium.org, mcgrathr@chromium.org Review URL: https://breakpad.appspot.com/5744002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1408 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Microdumps: support aarch64 and lib mapping from APKprimiano@chromium.org2014-12-0221-776/+148959
| | | | | | | | | | | | | | | | | | - Filter modules by prot flags (only +x) not extensions. It wouldn't otherwise catch the case of Chrome mapping the library from the apk (which is mapped r-x but doesn't end in .so). - Use compile-time detection of target arch, in order to cope with multilib OSes, where uname() doesn't reflect the run-time arch. - Add OS information and CPU arch / count. - Add support for aarch64. - Add tests and stackwalk expectations for aarch64. - Fix a potential overflow bug in the processor. - Rebaseline the tests using smaller symbols. - Fix microdump_writer_unittest.cc on 32-bit host. BUG=chromium:410294 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1407 4c0a9323-5329-0410-9bdc-e9ce6186880e
* Surfacing the process create time in google_breakpad::ProcessStateivanpe@chromium.org2014-11-2510-15/+123
| | | | | | | | | | | | | | | | | | | | | | | | | and updating minidump_stackwalk to show process uptime. I tested this with a minidump from Chrome and I got a result that is inline with what the Windows debugger is showing for that dump: minidump_stackwalk output: -------------------------- Process uptime: 601 seconds WinDBG output: -------------- Process Uptime: 0 days 0:10:01.000 I didn't update the machine readable output of minidump_stackwalk on purpose in order to avoid breaking someone that uses it. It can be added later to the machine output if needed. R=mark@chromium.org Review URL: https://breakpad.appspot.com/7754002 git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1406 4c0a9323-5329-0410-9bdc-e9ce6186880e
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-16 23:20:23 +0000