| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I9b69a23b308fe851ed49722c0da3953433b3f5b8
|
|
|
|
|
|
|
|
|
|
| |
Instead of method instrumentation, allow traceview to periodically
sample stack traces of threads. Disabled by default until we add
gui support for this new mode.
(cherry picked from commit 676f8a527fb62abd39663d55c7d9208f5ca03093)
Change-Id: Ia5d0d57012305a5830d042bcb903a429432b035b
|
|\
| |
| |
| |
| | |
* commit 'f694431279501527cc3271d50b619533000dbd8f':
Fix a minor bug in dvmCreateInterpThread
|
| |\ |
|
| | |
| | |
| | |
| | | |
Change-Id: I452ee02290bc7e0be7fefcf5755c5cd9628142dc
|
|\| |
| | |
| | |
| | |
| | | |
* commit 'f3079bdadf30d93b37e0a59a8787c636027a36f5':
Rename unreasonable function name dmvCompilerTemplateEnd
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In dalvik, most function names start with "dvm" except dmvCompilerTemplateEnd.
Convert it to dvmCompilerTemplateEnd in order to follow the rule.
Change-Id: I09c41f8c9d55058013fbdb62ac5922ccd067ce39
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This has been tracked down to a kernel bug, so we no longer need
the extra diagnostics.
Bug: 8470684
Change-Id: Ib170d1f7b94488ed4acc763f8dddc44c81807aed
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Threads just starting up or shutting down might not have any managed
stack frames, leading to a NULL "currFrame" frame pointer in the
interpreter stack.
Bug: 8596028
Change-Id: Ie24c8d5f8e78a5abe882a9e639046c03abb91649
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We've seen monkey crashes in this code, though I haven't been
able to reproduce them in my own SIGQUIT stress tests. Address
the two most likely causes of trouble: dumping the signal catcher's
own thread (which will always be runnable), and assuming that the
Method* pulled from the save area is non-NULL.
Bug: 8596028
Change-Id: I59d1dcb2264a774d8416d50a5f77a06c70d37c59
|
| |/
| |
| |
| |
| | |
Bug: 7432159
Change-Id: I83cb530155edfc35ae3be0f7a2a044245223d2d5
|
| |
| |
| |
| |
| | |
Bug: 8470684
Change-Id: I24d22d5ec4181614d173a582773540c8f712ab18
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | | |
Bug: 8856374
Change-Id: I58420a14fb52eab6295381a4d8f2d59eacfe0473
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This has been tracked down to a kernel bug, so we no longer need
the extra diagnostics.
Bug: 8470684
(cherry picked from commit 3a9dbd30eb1598c737af7ef6110d46767d6e0336)
Change-Id: I0877a24a5a409695c3a1a9ddb5c7c4d78e6a578e
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Threads just starting up or shutting down might not have any managed
stack frames, leading to a NULL "currFrame" frame pointer in the
interpreter stack.
Bug: 8596028
(cherry picked from commit 46371593812d966c40e1ec4019e3c7c6613046a6)
Change-Id: I0fbc6d422bcae0fd080f7c1a63198755235e9e00
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We've seen monkey crashes in this code, though I haven't been
able to reproduce them in my own SIGQUIT stress tests. Address
the two most likely causes of trouble: dumping the signal catcher's
own thread (which will always be runnable), and assuming that the
Method* pulled from the save area is non-NULL.
(cherry-pick of feddac5b7718dd8141391bfeb6359f1906542823.)
Bug: 8596028
Change-Id: I7a70ce047c8285715eb7bbb9438e8ef5d81fc59c
|
| |
| |
| |
| |
| |
| |
| |
| | |
Bug: 7432159
(cherry picked from commit 890ce010c4846deb82d3ac09b6d2ceb76e59fb67)
Change-Id: I12e9b6998f2119e0fabb5717e9c54c53f206d34f
|
|/
|
|
|
|
|
|
| |
Bug: 8470684
(cherry picked from commit 3eeda5e6fe172758e47d237694daf4f9421f3c12)
Change-Id: Ideba410d393b69753bbfae7558a2692edd08d339
|
|
|
|
|
|
|
|
|
|
| |
Let's try to get slightly better logging and exception detail messages.
Also fix the "set but not read" warnings for the other pthread functions
in this file.
Bug: 8470684
Change-Id: I7f9dbb4d39b4e3022cd5f1a8a45c6426e68c858b
|
|
|
|
|
|
| |
call pthread_attr_destroy in order to reclaim attribute object.
Change-Id: I2592903ef67101a7c656a3ab0ad243a9716298b5
|
|
|
|
| |
Change-Id: Ic2c9b88b2b3204b4c02f4838766dc4d9ebad06a2
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should allow us to differentiate between "couldn't get the
stack" and "didn't try to get the stack". Also show the thread's
state (e.g. 'R' for running, 'D' for uninterruptible syscall).
Bug 7053953
(cherry-pick of b3667a19f5c573b7785876979af4781292d27327.)
Change-Id: I0a40cb3d3cdd9aef8589a39586cccd9c229aa8cb
|
|\
| |
| |
| | |
Change-Id: I9c1f2e37602bea86e70333d2b274665e99fcbd92
|
| |
| |
| |
| |
| |
| |
| |
| | |
Change-Id: I9bb4f6875b7061d3ffaee73f204026cb8ba3ed39
Signed-off-by: Raghu Gandham <raghu@mips.com>
Signed-off-by: Chris Dearman <chris@mips.com>
Signed-off-by: Douglas Leung <douglas@mips.com>
Signed-off-by: Don Padgett <don@mips.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Found by someone reading the code, rather than because we saw a crash. This is
only a small leak, and you'd have to be dumping threads (because of an ANR) or
creating a new thread to provoke it.
(cherry picked from commit 6d1a1dfd0ef006e19067b6ffd927160d0c6d9647)
Change-Id: Id857efca8d34b20d1acaa452c3fe5d2975e2572b
|
| |
| |
| |
| |
| |
| |
| | |
Similar to -Xss, but for the main thread only.
Bug: 6315322
Change-Id: I84bd5974f830f348fd9a0486ae972520b4a02cc4
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Mostly these are boring, but when they're boring they're also short.
And sometimes they're interesting.
Bug: 6294717
Change-Id: I1bf9e32a5cc237efda365abe39ad84ac59fd5c8f
|
| |
| |
| |
| |
| |
| |
| |
| | |
Found by someone reading the code, rather than because we saw a crash. This is
only a small leak, and you'd have to be dumping threads (because of an ANR) or
creating a new thread to provoke it.
Change-Id: I9c660d86056765bcbebbdfa634032885c3f91b82
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
See https://android-git.corp.google.com/g/#/c/157220
Also fix an occurrence of LOGW missed in an earlier change.
Bug: 5449033
Change-Id: I2e3b23839e6dcd09015d6402280e9300c75e3406
|
| |
| |
| |
| |
| |
| |
| | |
See https://android-git.corp.google.com/g/157065
Bug: 5449033
Change-Id: Ia5d301248024df26c2a29dabdfe738e39ec87c82
|
| |
| |
| |
| |
| |
| |
| | |
See https://android-git.corp.google.com/g/156801
Bug: 5449033
Change-Id: Ic558031c75b3702d90eb78bd730501ae5d3c077b
|
| |
| |
| |
| |
| |
| |
| | |
See https://android-git.corp.google.com/g/156016
Bug: 5449033
Change-Id: Ic663376d1ad6a6cb14bf81405ad9afd247cf2f60
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Bug: 5544153
We are seeing cases where dumping certain non-Dalvik threads
causes system instability. Temporarily disable this feature.
Change-Id: I14d7907a90f152bcb15d066f8bd3fdedc578e722
|
| |
| |
| |
| | |
Change-Id: I276f5f448f22f8a926cdfc8c93935da687db5d9b
|
| |
| |
| |
| |
| |
| |
| | |
See https://android-git.corp.google.com/g/#/c/143865
Bug: 5449033
Change-Id: I8bd96961e369a08e86ff78b82d90f20f42787eb1
|
|/
|
|
| |
Change-Id: I7da7259f1350e853153ba4dea96797fc86284068
|
|
|
|
|
|
|
| |
The main purpose here was to have slightly less unclear warnings for
JNI local reference abuse.
Change-Id: I2c6378dd0a94d8afb96a8e409f7460205e3cd315
|
|
|
|
|
|
|
| |
These aren't necessarily good abstractions, but they're no worse than what
we had, and having them factored out is a step in the right direction.
Change-Id: I5b839608317d2ca1ca54d8a38624fb686f2c37de
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, when we're waiting on a Class, say which class:
I(16573) - waiting on <0xf5ed54f8> (java.lang.Class<java.lang.ref.ReferenceQueue>)
versus:
I(16573) - waiting on <0xf5feda38> (a java.util.LinkedList)
Bug: http://code.google.com/p/android/issues/detail?id=17349
Change-Id: I844d02c008b1499adb02995ff3da25ba8cad0e0a
|
|
|
|
|
|
|
| |
This changes all the places I could find where the log string was on the
line after its LOG call.
Change-Id: Iac6a9fcc64f46631fb093824ab60237dce1a5241
|
|
|
|
|
|
| |
Friends don't let friends end LOG() strings with newlines.
Change-Id: I5a18c766c90c4ab5f03caa6acd601d34d91beb00
|
|
|
|
| |
Change-Id: I3093925668eef9a839fc9fc490fc8260c001b777
|
|
|
|
|
|
|
|
|
| |
Moved the suspend count variables from the interpBreak structure. These
are already protected by a mutex, and we need the space in interpBreak
for additional subMode flags. This CL just does the move and expands
the width of subMode to 16-bits.
Change-Id: I4a6070b1ba4fb08a0f6e0aba6f150b30f9159eed
|
|
|
|
|
|
|
| |
We ended up with two locations in the Thread structure for saved
Dalvik frame pointer. This change consolidates them.
Change-Id: I78f288e4e57e232f29663be930101e775bfe370f
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original implementation for thin locks used a magic non-zero value
to encode the initial thin lock state. This magic value was kept
around in DVM_LOCK_INITIAL_THIN_VALUE and stored into the lock word of
newly allocated objects. A later revision to the thin locking code
made the initial thin lock value be 0. That change eliminated the
requirement that lock words be explicitly initialized as the allocator
always returns zero-filled memory.
Change-Id: I34e0b43b4c4db0f45cf7cf524e15d4a6096c1365
|
|
|
|
| |
Change-Id: Ica749f6defa890363ec531b29e25bc415dc2cbb9
|
|
Change-Id: Id8693208d2741c55a7b0474d1264f2112019d11f
|