-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
5.0
-
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 <###@###.###>
======================================================================
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 <###@###.###>
======================================================================
- duplicates
-
JDK-4897519 JVMTI GetThreadStatus() returns wrong status for finished thread
-
- Closed
-