diff options
| author | 2024-01-24 13:22:03 -0800 | |
|---|---|---|
| committer | 2024-01-29 03:56:34 +0000 | |
| commit | b782659336403e125e33f829afad49b901027c22 (patch) | |
| tree | cc5c47dfeb8cd829216385989bad594ec07ab9c4 /compiler/optimizing/nodes.h | |
| parent | 6f13c5541443a0a98c2c0d71228c8af75bc4fddc (diff) | |
Abort in culprit thread for suspend timeout
When we time out trying to suspend t, send t a SIGABRT, and have it
print the abort message and hopefully dump its stack at the correct
point. Otherwise we generated thread dumps after the offending thread
had responded to a checkpoint, which were less likely to be informative.
Make Thread::GetThreadName() a bit more robust.
Reduce duplication of lock-level complaints when waiting on a condvar.
That was making this hard to debug.
Factor out SetAbortMessage() so we can reuse it. Unconditionally
set the message in the current Runtime.
Document why calling WaitForSuspendBarrier with the mutator lock held
is sometimes marginally OK. I was concerned that this was causing
suspend failures, but I don't think it is.
Add kShortSuspendTimeouts for testing. This should never be enabled in
production or for routine testing, but I found myself regularly
reinserting this code.
SuspendThreadByPeer was not yet updated, since we're not currently
seeing a lot of failures there, and it should be merged with
SuspendThreadByThreadId once the current bugs are addressed.
Test: Local host run-tests. TreeHugger.
Test: Confirm that kShortSuspendTimeouts failures look reasonable.
Bug: 321625381
Bug: 297973401
Change-Id: I151f4ed2a2aefff6026a04314d6b1ec287ed7dcd
Diffstat (limited to 'compiler/optimizing/nodes.h')
0 files changed, 0 insertions, 0 deletions