tree e50982b5aa45ea114b0ea456be61efe803e55c53
parent ceef4a517dac6bf87b2f12549ac8fd0e9acb6a62
author Lars Volker <lv@cloudera.com> 1515449347 -0800
committer Mike Frysinger <vapier@chromium.org> 1515514927 +0000

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>