aboutsummaryrefslogtreecommitdiff
path: root/src/client/windows/crash_generation
diff options
context:
space:
mode:
authorLars Volker <lv@cloudera.com>2018-01-08 14:09:07 -0800
committerMike Frysinger <vapier@chromium.org>2018-01-09 16:22:07 +0000
commit97a98836768f8f0154f8f86e5e14c2bb7e74132e (patch)
treee50982b5aa45ea114b0ea456be61efe803e55c53 /src/client/windows/crash_generation
parentFixed file extention for minidump_upload in tools_linux.gypi (diff)
downloadbreakpad-97a98836768f8f0154f8f86e5e14c2bb7e74132e.tar.xz
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>
Diffstat (limited to 'src/client/windows/crash_generation')
0 files changed, 0 insertions, 0 deletions