Improve handling of daemon threads after runtime shutdown
The main issue comes from the fact that user daemon threads are
allowed to continue running after the runtime has shutdown. They may
still have a JNI env pointer. To prevent crashing if they call into
the env, we replace the function pointers with functions that sleep
forever.
The other issue is that user daemon threads that are blocked in an
ART condition variable may get woken up by another user daemon inside
of Monitor::Notify or by a spurious wakeup (i.e. SIGQUIT). To deal
with this issue, we check the JNI env for shutdown runtime when we
are woken up from a condition variable wait. This check fixes test
132 with --host --gdb --interpreter. Previously this test crashed
since dlclose was somehow causing a spurious futex wakeup.
TODO: Investigate adding a unit test.
Bug: 18577101
Change-Id: I479b38968ee9fbc4ee4b252ee2528787279972cc
diff --git a/runtime/base/mutex.cc b/runtime/base/mutex.cc
index 70bd398..82a5f96 100644
--- a/runtime/base/mutex.cc
+++ b/runtime/base/mutex.cc
@@ -855,6 +855,18 @@
PLOG(FATAL) << "futex wait failed for " << name_;
}
}
+ if (self != nullptr) {
+ JNIEnvExt* const env = self->GetJniEnv();
+ if (UNLIKELY(env != nullptr && env->runtime_deleted)) {
+ CHECK(self->IsDaemon());
+ // If the runtime has been deleted, then we cannot proceed. Just sleep forever. This may
+ // occur for user daemon threads that get a spurious wakeup. This occurs for test 132 with
+ // --host and --gdb.
+ // After we wake up, the runtime may have been shutdown, which means that this condition may
+ // have been deleted. It is not safe to retry the wait.
+ SleepForever();
+ }
+ }
guard_.ExclusiveLock(self);
CHECK_GE(num_waiters_, 0);
num_waiters_--;