summaryrefslogtreecommitdiff
path: root/rs/java/android/renderscript/ProgramFragmentFixedFunction.java
diff options
context:
space:
mode:
authorJeff Sharkey <jsharkey@android.com>2016-12-06 16:47:00 -0700
committerJeff Sharkey <jsharkey@google.com>2016-12-07 06:31:50 +0000
commit58f27b5033542150a78fb050e2f85253a48efa67 (patch)
tree9e8e223ddaa2c2f38c5e5b796e804368621ddacd /rs/java/android/renderscript/ProgramFragmentFixedFunction.java
parent598e9a7f41c714b6ccac05dea0d63e9274af7739 (diff)
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. Test: builds, boots Bug: 32575987 Change-Id: Ie8373ca277296f920f2b1c564d419c702a8ee0f2
Diffstat (limited to 'rs/java/android/renderscript/ProgramFragmentFixedFunction.java')
0 files changed, 0 insertions, 0 deletions