History log of /system/core/libbacktrace/ThreadEntry.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
7e2cb84e9c41e993daf7fac0b18335d6fe6f9acb 29-May-2015 Christopher Ferris <cferris@google.com> Modify the code to avoid potential deadlocks.

If the signal to dump a thread is never delivered, then it's
possible for a deadlock. The signal handler is responsible for
unlocking and deleting the ThreadEntry created for the pid/tid
combination. This means if the signal is lost, the ThreadEntry
gets stuck locked and never deleted. If a second attempt to get
a backtrace of this thread occurs, there is a deadlock.

Also, decrease the timeout from 10 seconds to 5 seconds. The original
10 seconds was because the unwind was actually done in the signal
handler. Now the signal handler does nothing but copy the ucontext
structure and let the caller do the unwind.

Bug: 21086132
(cherry picked from commit 2d09171758b7d98c77f27e439a4caf35dd84c311)

Change-Id: I414c500eb08983a5017caf3fce4f499465575a9d
/system/core/libbacktrace/ThreadEntry.cpp
2c43cff01d1271be451671567955158629b23670 27-Mar-2015 Christopher Ferris <cferris@google.com> Refactor the code.

The object hierarchy was confusing and convoluted. This removes
a lot of unnecessary code, and consolidates the BacktraceCurrent
and BacktraceThread code into BacktraceCurrent.

Change-Id: I01c8407d493712a48169df49dd3ff46db4a7c3ae
/system/core/libbacktrace/ThreadEntry.cpp