After handling an uncaught NSException, release the Breakpad object
so there will not be a second crash dump logged.
Prior to this change, for every uncaught NSException handled through
the Breakpad::UncaughtExceptionHandler(), a second crash without
any useful information (generally __cxa_rethrow and std::__terminate)
is recorded.
R=qsr@chromium.org
Review URL: https://breakpad.appspot.com/9664002
Patch from Peter Lee <pkl@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1344 4c0a9323-5329-0410-9bdc-e9ce6186880e
This bug manifests itself on Android x64 (in ExceptionHandlerTest::ExternalDumper), but is possible on any platform.
The compiler is unaware of the code which runs in the signal handler which reads this variable. Without volatile the compiler is free to optimise away writes to this variable which it believes are never read.
BUG=381142, 346626
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/8664002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1343 4c0a9323-5329-0410-9bdc-e9ce6186880e
- Convert time_t values to UTC correctly. It is incorrect to cast a uint32_t*
to time_t* because the two types may have different widths. This is the
case on many 64-bit systems, where time_t is a 64-bit signed integer.
Conversion is unified in a single function, and additional uses of time_t
in minidump files not previously displayed in UTC are now displayed.
- Interpret the IMAGE_DEBUG_MISC structure correctly.
- When printing MINIDUMP_SYSTEM_INFO structures, always show the "x86" side
of the union, and state whether it's expected to be valid. (Existing
Breakpad-produced non-Windows minidumps for x86_64 use the "x86" side of
union, but Windows minidumps for x86_64 use the "other" side, so I want to
print both.)
R=ivanpe@chromium.org
Review URL: https://breakpad.appspot.com/5674002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1339 4c0a9323-5329-0410-9bdc-e9ce6186880e
This fixes exception_handler.cc:77:8: error: fields must have a constant size:
'variable length array in structure' extension will never be supported
char protected_buffer[PAGE_SIZE] __attribute__((aligned(PAGE_SIZE)));
BUG=None
TEST=breakpad builds on ios8
R=mark@chromium.org
Review URL: https://breakpad.appspot.com/9654002
Patch from Justin Cohen <justincohen@chromium.org>.
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1338 4c0a9323-5329-0410-9bdc-e9ce6186880e
This CL introduces "--sobasedir" command-line option to minidump-2-core.
By default, paths to shared lib files included in generated core file are
formatted as "/var/lib/breakpad/[GUID]libFoobar.so". By using "--sobasedir",
this will be "[user-supplied-path]libFoobar.so".
This option can be used to ease debugging minidump files from developer's local
builds. By specifying "minidump-2-core --sobasedir `pwd`/out/Debug/lib/
foobar.mdmp", user can load the generated core file in gdb without setting up
the symlinks for "/var/lib/breakpad".
BUG=None
A=kouhei@chromium.org
Original code review: https://breakpad.appspot.com/1214002/R=kouhei@chromium.org
Review URL: https://breakpad.appspot.com/1584002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1317 4c0a9323-5329-0410-9bdc-e9ce6186880e
This has a substantial performance improvement over using the getSymbolsByAddr iterator, especially on certain 64bit DLLS. e.g. Time to process chrome_child.dll drops from 51 minutes to 21 secs.
Note: new test data looks different because the ordering of lines is no longer by memory address. This does not affect processing. The test data has been manually compared to old data and matches (except additional PUBLIC symbols). Also, INFO lines are omitted because the source executable files are not checked in, so they are unavailable.
R=ivanpe@chromium.org, mark@chromium.org
Review URL: https://breakpad.appspot.com/1574002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1316 4c0a9323-5329-0410-9bdc-e9ce6186880e
After r1299, the LinuxCoreDumperTest::VerifyDumpWithMultipleThreads and
ElfCoreDumpTest::ValidCoreFile would both hang on Android. This appears to be due to the tkill
signal not being recieved by the thread which is meant to crash, even though tkill returns 0.
This CL retries sending the tkill signal multiple times, which prevents the Hang.
BUG=579
R=thestig@chromium.org
Review URL: https://breakpad.appspot.com/1524002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1313 4c0a9323-5329-0410-9bdc-e9ce6186880e
As part of that:
- Updated MSSymbolServerConverter to also download the executable files from the symbol server and pass them to the PDBSourceLineWriter as it is required for successful conversion of symbols for 64-bit modules.
- Added a .gyp file and target for the ms_symbol_server_converter library.
- Updated PDBSourceLineWriter to allow executable files to be in locations different from the locations of the PDB files.
- Minor style issue:
* #define guards.
* No space before ')' and after '('.
R=mark@chromium.org, wfh@chromium.org
Review URL: https://breakpad.appspot.com/1434002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1309 4c0a9323-5329-0410-9bdc-e9ce6186880e
The ElfCoreDumpTest.ValidCoreFile unit test assumed that the number of
NT_FPREGSET / NT_PRXFPREG notes in the core dump file equals to the number of
threads of the crashed process. This assumption isn't always true as the kernel
skips filling the NT_FPREGSET / NT_PRXFPREG note of a thread if the FPU state
isn't available. The kernel indicates the availability of NT_FPREGSET /
NT_PRXFPREG via the pr_fpvalid field of the NT_PRSTATUS note. This CL modifies
the ElfCoreDumpTest.ValidCoreFile unit test to verify the number of NT_FPREGSET
and NT_PRXFPREG notes based on the pr_fpvalid field of the NT_PRSTATUS notes.
BUG=577
TEST=Run unit tests on x86 and x86_64 Linux platform.
R=vapier@chromium.org
Review URL: https://breakpad.appspot.com/1404002
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1303 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
The current CreateChildCrash logic is racy when it comes to creating a
crash dump for two reasons:
The main thread that calls kill() on a different thread is guaranteed
the signal will be *queued* when it returns, but not *delivered*. If
the kernel doesn't automatically schedule the receiving thread, but
instead lets the main thread run to the exit() call, then the signal
never triggers a coredump and the whole process simply exits.
The main thread is using kill() to try to deliver a signal to a
specific thread, but that function is for sending signals to a
process. That means the kernel is free to deliver the signal to
any thread in the process and not just the one requested. This
manifests itself as the pr_pid in the coredump not being the one
expected. Instead, we must use tkill() with the tid (which we
already took care of gathering) to deliver to a specific thread.
These are a lot easier to see on a UMP system as contention is heavier.
BUG=chromium:207918
TEST=`dumper_unittest` still passes, and doesn't flake out in a UMP system
TEST=`linux_client_unittest` still passes
R=benchan@chromium.org
Review URL: https://breakpad.appspot.com/1304005
git-svn-id: http://google-breakpad.googlecode.com/svn/trunk@1299 4c0a9323-5329-0410-9bdc-e9ce6186880e
