Correct long-standing thread status change bug.

If the stars aligned correctly (or you were running valgrind), it was
possible for a thread to change its status to RUNNING immediately after
having its suspend count incremented.  The problem is that the thread
initiating the suspension regards the target thread as being in (say)
VMWAIT with sCount=1, which means its safe to kick off a GC.  The target
thread thinks it's happily in RUNNING and can go do whatever it wants.

The fix is to move the status change so that it's guarded by the
suspension count mutex.

This shouldn't affect performance.  The number of instructions executed
is about the same.

Also, the "self can be NULL" feature of dvmCheckSuspendPending had very
few customers, so we now skip that check and just require it to be set.

For bug 2309331.

Change-Id: Id512e16e321515a467c20b382c85017cef9cea4d

1 files changed, 2 insertions, 2 deletions

diff --git a/vm/Thread.h b/vm/Thread.h
index 29cbec64c..4956009b7 100644
--- a/vm/Thread.h
+++ b/vm/Thread.h
@@ -44,6 +44,8 @@ struct LockedObjectData;
  * Note that "suspended" is orthogonal to these values (so says JDWP).
  */
 typedef enum ThreadStatus {
+    THREAD_UNDEFINED    = -1,       /* threads are never in this state */
+
     /* these match up with JDWP values */
     THREAD_ZOMBIE       = 0,        /* TERMINATED */
     THREAD_RUNNING      = 1,        /* RUNNABLE or running now */
@@ -328,8 +330,6 @@ void dvmWaitForSuspend(Thread* thread);
 /*
  * Check to see if we should be suspended now.  If so, suspend ourselves
  * by sleeping on a condition variable.
- *
- * If "self" is NULL, this will use dvmThreadSelf().
  */
 bool dvmCheckSuspendPending(Thread* self);