OSDN Git Service

Fix two StrictMode stack collection bugs.
authorJeff Sharkey <jsharkey@android.com>
Tue, 6 Dec 2016 23:47:00 +0000 (16:47 -0700)
committerBrian Carlstrom <bdc@google.com>
Wed, 7 Dec 2016 16:58:38 +0000 (08:58 -0800)
commit20db11cfdab0e2838308847e644d9e6d4c31079b
tree1d871daa1bdc25a062038b845df6b26852d591a5
parentd95fc2d4c9103cab004931ecd22cbcfa9fcfd546
Fix two StrictMode stack collection bugs.

When Binder calls are nested, we can quickly end up with a snowball
of stacktraces that can cause the original transaction to fail.  This
CL makes two specific changes to alleviate this pressure:

-- Consider a nested Binder call from PID A -> B -> C.  If both B and
C encounter dozens of StrictMode violations, then gatheredViolations
in B will end up with 10 ViolationInfo (5 from B and 5 from C).  This
problem only grows with each successive nested call.  To solve this,
always limit ourselves to only ever write out 3 ViolationInfo from
any given process.

-- CrashInfo already nicely truncates any large stack traces to 20kB,
but readAndHandleBinderCallViolations() blindly appends the entire
local trace, and never considers truncating again.  Similar to the
first problem above, nested calls can quickly cause the stackTrace
value to explode in size.  To solve this, we always re-truncate the
stackTrace value after appending our local stack.

Also fix some NPE bugs when missing crashInfo.

(cherry-picked from commit 58f27b5033542150a78fb050e2f85253a48efa67)

Test: builds, boots
Bug: 32575987
Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
core/java/android/app/ApplicationErrorReport.java
core/java/android/os/StrictMode.java