Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4932344

jvmti/GetThreadStatus/thrstat003 gets RUNNABLE when it should get SLEEPING

XMLWordPrintable

    • generic
    • generic

      ###@###.### 2003-10-03

      The testbug affects the following NSK test:

          nsk/jvmti/GetThreadStatus/thrstat003

      This test failed the 2003.10.02 PIT testing cycle for Tiger-B23 VM snapshot.

      The test log shows two failures:

      Wrong status: JVMTI_THREAD_STATUS_RUNNABLE (1),
          expected: JVMTI_THREAD_STATUS_SLEEPING (2)
      Wrong status: JVMTI_THREAD_STATUS_NOT_STARTED (5),
          expected: JVMTI_THREAD_STATUS_ZOMBIE (0)

      I believe the second failure (STATUS_NOT_STARTED instead of STATUS_ZOMBIE)
      is due to the following known bug:

      4897519 3/4 JVMTI GetThreadStatus() returns wrong status for finished thread

      That leaves the first failure (STATUS_RUNNABLE instead of STATUS_SLEEPING).
      I believe there is a race in the test that is causing the first failure
      mode.

      There are two worker threads in this test. The first is "main" and that
      thread is checking the various status values returned for the second worker
      thread that I'll call "target".

      Here is a transaction diagram for the part of the test with the race:

      main target
      ======================= ======================
      enter(lock)
      target.start
      : enter(lock) blocks
      lock.wait() :
      : enter(lock) returns
      : lock.notify()
      : exit(lock)
      reenter(lock) :
      exit(lock) sleep(2 minutes)
      check(target, SLEEPING) :
      target.interrupt() :
                               sleep() returns

      After the target thread exits the lock, there is no guarantee when
      the thread will be scheduled again. So there is no guarantee when the
      target thread will call sleep(2 minutes).

      I believe this is why the 'check(target, SLEEPING)' call is failing.
      The target thread hasn't called sleep() yet so the check fails.



      Name: ipR10196 Date: 10/06/2003


      This bug affects also the following JVMTI tests:

        nsk/jvmti/scenarios/sampling/SP01/sp01t002
        nsk/jvmti/scenarios/sampling/SP01/sp01t003

      These tests check threads status before and after suspending and
      resuming tested threads. The threads status is checked in a
      waiting loop to ensure threads to reach expected state.

      These tests also demonstrate that no JVMTI_THREAD_STATUS_INTERRUPTED
      is returned for an interrupted thread.

      Here is the tests output:

      # ERROR: sp01t002.c, 279: Unexpected status of not suspended thread #3 (threadSleeping):
      # got status: JVMTI_THREAD_STATUS_RUNNABLE (1)
      # expected: JVMTI_THREAD_STATUS_SLEEPING (2)
      # ERROR: sp01t002.c, 309: No INTERRUPTED status flag for not suspended thread #4 (threadRunningInterrupted):
      # got flags: <none> (0)
      # ERROR: sp01t002.c, 279: Unexpected status of suspended thread #3 (threadSleeping):
      # got status: JVMTI_THREAD_STATUS_RUNNABLE (1)
      # expected: JVMTI_THREAD_STATUS_SLEEPING (2)
      # ERROR: sp01t002.c, 309: No INTERRUPTED status flag for suspended thread #4 (threadRunningInterrupted):
      # got flags: JVMTI_THREAD_STATUS_FLAG_SUSPENDED (1)
      # ERROR: sp01t002.c, 279: Unexpected status of resumed thread #3 (threadSleeping):
      # got status: JVMTI_THREAD_STATUS_RUNNABLE (1)
      # expected: JVMTI_THREAD_STATUS_SLEEPING (2)
      # ERROR: sp01t002.c, 309: No INTERRUPTED status flag for resumed thread #4 (threadRunningInterrupted):
      # got flags: <none> (0)

      Ivan Popov <###@###.###>


      ======================================================================

            swamyv Swamy Venkataramanappa
            dcubed Daniel Daugherty
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: