| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the fields we save might have signed types depending on the
system (e.g. `typedef int pid_t`). Depending on the toolchain, we
can trip -Werror=narrowing failures like:
src/client/linux/minidump_writer/linux_core_dumper.cc:248:66: error:
narrowing conversion of ‘(__pid_t)info->siginfo_t::_sifields.siginfo_t::<anonymous union>::_kill.siginfo_t::<anonymous union>::<anonymous struct>::si_pid’
from ‘__pid_t {aka int}’ to ‘long unsigned int’ inside { } [-Werror=narrowing]
set_crash_exception_info({info->si_pid, info->si_uid});
^^^^^^
src/client/linux/minidump_writer/linux_core_dumper.cc:252:71: error:
narrowing conversion of ‘(int)info->siginfo_t::_sifields.siginfo_t::<anonymous union>::_sigsys.siginfo_t::<anonymous union>::<anonymous struct>::_syscall’
from ‘int’ to ‘long unsigned int’ inside { } [-Werror=narrowing]
set_crash_exception_info({info->si_syscall, info->si_arch});
^^^^^^^^^^
Since the exception info fields are all uint64_t which should be large
enough to handle all the fields in the siginfo_t structure, add casts
for all the assignments to avoid these errors. We have implicit casts
even without them, so we aren't changing behavior.
Bug: google-breakpad:791
Bug: chromium:945653
Change-Id: Ib04e015998f08b857159ac13e9a065a66d228d49
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1544862
Reviewed-by: Mark Mentovai <mark@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If the kernel/C library headers are old, they might not have the
fields needed for SIGSYS decoding. Add ifdef checks for that and
skip the logic entirely. Easier than adding arch-specific siginfo
structs to the codebase.
Bug: google-breakpad:791
Change-Id: Ia473e3ffa61fce4c42cf4c1e73a9df044599bc5c
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1524447
Reviewed-by: Mark Mentovai <mark@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Many signals in Linux support additional metadata on a per-signal
basis. We can extract that from NT_SIGINFO and pass it through
in the exception_information fields.
The current core dumper logic doesn't set exception_information
at all, so this is an improvement.
Bug: google-breakpad:791
Change-Id: I38b78d6494e9bc682441750d98ac9be5b0656f5a
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1497662
Reviewed-by: Mark Mentovai <mark@chromium.org>
|
| |
|
|
|
|
|
|
|
|
| |
When building on an old system with outdated headers, this define
might not be available. Add a fallback to our existing elf header.
Bug: google-breakpad:790
Change-Id: I4dfe7a5cebd414cca3582a1a9cfc983503d5a779
Reviewed-on: https://chromium-review.googlesource.com/c/breakpad/breakpad/+/1507073
Reviewed-by: Mark Mentovai <mark@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current core dumper only parses NT_PRSTATUS notes. With signal
details, this note only includes three fields: signo, code, and errno.
We set exception_code to signo and exception_flag to code. The errno
value isn't set by the kernel, so there's no need to save it.
However, we never fill in exception_address which means all converted
crashes look like they happen at address 0. This implies a NULL jump
which is usually not the case, so it's just confusing. The prstatus
structure doesn't offer anything directly that tracks this.
Starting with linux-3.7, the kernel writes out the full siginfo
structure in the NT_SIGINFO note. So lets support that to pull out
si_addr which, for a bunch of common signals, is the value we want in
exception_address.
The size of the siginfo_t structure should be locked to 128 bytes at
build time for all architectures, so this should hopefully be stable.
Bug: google-breakpad:790
Change-Id: I458bad4787b1a8b73fad8fe068e9f23bec957599
Reviewed-on: https://chromium-review.googlesource.com/c/1497661
Reviewed-by: Mark Mentovai <mark@chromium.org>
|
| |
|
|
|
|
|
|
|
| |
Store the information in the exception record's exception_information
field.
Change-Id: Ie215cae2f070fdab63c3d05cc1bc4fb4b7b095fa
Reviewed-on: https://chromium-review.googlesource.com/990799
Reviewed-by: Mark Mentovai <mark@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
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/
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APK file.
This patch makes two changes to breakpad to enable crash reporting to work correctly when the library is inside another file (an archive):
- Do not filter mappings which map an executable at a non-zero offset.
- If such an executable is mapped look in the ELF information for the
shared object name and use that name in the minidump.
Note this change doesn't care about the archive format and isn't Android
specific (though loading the shared library this way is currently only done on Android).
BUG=390618
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/7684002
Patch from Anton Carver <anton@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1355 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes failing unittests in Android on MIPS:
LinuxCoreDumperTest.VerifyDumpWithMultipleThreads
ElfCoreDumpTest.ValidCoreFile
BUG=None
TEST=Running breakpad_unittests on MIPS Android device
Review URL: https://breakpad.appspot.com/3664002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1330 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an initial attempt to add Arm64 (aarch64) support to Breakpad for
Linux / Android platforms. This CL adds the Arm64 data structures, but does
not yet implement the Android getcontext support or CPUFillFromThreadInfo /
CPUFillFromUContext.
BUG=354405,335641
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/1354002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1301 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Support for mips cpu is added to all breakapad targets including unittests.
BUG=none
TEST=unittests
Review URL: https://breakpad.appspot.com/614002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1212 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if a thread's stack pointer is not within a valid memory page,
the minidump writing will fail with an error. This change allows an invalid
stack pointer by simply setting the memory size to zero in the minidump.
The processing code already checks for the size being zero, although it
currently just gives an error (see https://breakpad.appspot.com/413002/).
BUG=google-breakpad:499, chromium-os:34880
TEST=make check, manually ran minidump-2-core and core2md
Review URL: https://breakpad.appspot.com/478002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1065 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
|
|
This patch is part of a bigger patch that helps merging the breakpad code
with the modified version in Chromium OS.
Specifically, this patch makes the following changes:
1. Turn the LinuxDumper class into a base class and move ptrace related
code into a new derived class, LinuxPtraceDumper.
2. Add a LinuxCoreDumper class, which is derived from LinuxDumper, to
extract information from a crashed process via a core dump file instead
of ptrace.
3. Add a WriteMinidumpFromCore function to
src/client/linux/minidump_writer/minidump_writer.h,
which uses LinuxCoreDumper to extract information from a core dump file.
4. Add a core2md utility, which simply wraps WriteMinidumpFromCore, for
converting a core dump to a minidump.
BUG=455
TEST=Tested the following:
1. Build on 32-bit and 64-bit Linux with gcc 4.4.3 and gcc 4.6.
2. Build on Mac OS X 10.6.8 with gcc 4.2 and clang 3.0 (with latest gmock).
3. All unit tests pass.
4. Run Chromium OS tests to test core2md.
Review URL: http://breakpad.appspot.com/343001
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@905 4c0a9323-5329-0410-9bdc-e9ce6186880e
|
