| commit | 97a98836768f8f0154f8f86e5e14c2bb7e74132e | [log] [tgz] |
|---|---|---|
| author | Lars Volker <lv@cloudera.com> | Mon Jan 08 22:09:07 2018 |
| committer | Mike Frysinger <vapier@chromium.org> | Tue Jan 09 16:22:07 2018 |
| tree | e50982b5aa45ea114b0ea456be61efe803e55c53 | |
| parent | ceef4a517dac6bf87b2f12549ac8fd0e9acb6a62 [diff] |
Only restore the signal handler if sigaction has not changed Restoring the signal handler in ExceptionHandler::SignalHandler() can lead to a race in scenarios where multiple threads crash within a short time. This can cause threads to alternately try to write a minidump without ever terminating the process. The first thread to write a minidump will reset the signal handler to the SIG_DFL using signal() in InstallDefaultHandler(). The next thread to execute SignalHandler() will detect this and will reset the signal handler to SignalHandler(). If the first thread takes too long to write its minidump (e.g. when there are many threads), the chances increase that the second thread will enter SignalHandler() before the first one leaves the critical section. After resetting the signal handler, the second thread will fail to write a minidump (since the file already exists) and will try to reset the signal handler to the default by calling RestoreHandlersLocked(). However, in the meantime the first thread will have entered SignalHandler() again and will overwrite it one more time. After that, no further attempts will be made to restore the default signal handler and both threads will continue to re-raise the signal and attempt to write minidump files. This change adds a check to make sure that cur_handler.sa_sigaction is still pointing to SignalHandler() before re-installing the handler. To test this we start a large number of sleeping threads and two threads that will crash simultaneously. Without the fix, this would reproducibly lead to a loop between the two crashing threads. Bug: 752 Change-Id: I784328cfff17ddc7476d6668354570ab867ba405 Reviewed-on: https://chromium-review.googlesource.com/855137 Reviewed-by: Mike Frysinger <vapier@chromium.org>
Breakpad is a set of client and server components which implement a crash-reporting system.
First, download depot_tools and ensure that they’re in your PATH.
Create a new directory for checking out the source code (it must be named breakpad).
mkdir breakpad && cd breakpad
Run the fetch tool from depot_tools to download all the source repos.
fetch breakpad
cd src
Build the source.
./configure && make
You can also cd to another directory and run configure from there to build outside the source tree.
This will build the processor tools (src/processor/minidump_stackwalk, src/processor/minidump_dump, etc), and when building on Linux it will also build the client libraries and some tools (src/tools/linux/dump_syms/dump_syms, src/tools/linux/md2core/minidump-2-core, etc).
Optionally, run tests.
make check
Optionally, install the built libraries
make install
If you need to reconfigure your build be sure to run make distclean first.
To update an existing checkout to a newer revision, you can git pull as usual, but then you should run gclient sync to ensure that the dependent repos are up-to-date.
Follow the steps above to get the source and build it.
Make changes. Build and test your changes. For core code like processor use methods above. For linux/mac/windows, there are test targets in each project file.
Commit your changes to your local repo and upload them to the server. http://dev.chromium.org/developers/contributing-code e.g. git commit ... && git cl upload ... You will be prompted for credential and a description.
At https://chromium-review.googlesource.com/ you'll find your issue listed; click on it, then “Add reviewer”, and enter in the code reviewer. Depending on your settings, you may not see an email, but the reviewer has been notified with google-breakpad-dev@googlegroups.com always CC’d.