JDK-4875995 : Thread.stop() and Stop thread mechanism is not working in hotspot VM.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.2,5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2003-06-09
  • Updated: 2008-07-23
  • Resolved: 2003-11-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2Resolved
Related Reports
Relates :  
JDK-4814343 - JDI method ThreadReference.stop(throwable) may hang up debuggee
Description
This bug affects the following tests from testbase_nsk:
 
    nsk/jdb/kill/kill001


Thread stop mechanism is not working in 1.4.2 and 1.5. Thread.Stop() is 
deprecated but jvmdi/jvmti still need this functionality.

I am attaching a test case which is modified from jvmdi test case
which does not use jvmdi interface. 

Expected output:

=>/java/re/jdk/1.4.1/latest/binaries/solaris-sparc/bin/java kill001a
Thread started: MyThread-0
Thread started: MyThread-1
Thread started: MyThread-2
Thread started: MyThread-3
Thread started: MyThread-4
notKilled == 0   <========== This indicates all threads stopped.

Current output:
Thread started: MyThread-0
Thread started: MyThread-1
Thread started: MyThread-2
Thread started: MyThread-3
Thread started: MyThread-4
notKilled == 4        <====== This indicates Thread.stop() did not stop
			       4 java threads and it continued to execute.

Signal mechanism used to stop thread seems to be broken. I do not know
the details yet.



###@###.### 2003-06-19
 

After adding a Thread.sleep() in the code it seems to work 
fine. Looks like adding any statement in the code which
makes thread transition from Java to VM seems to work.
And I wonder why synchronized (kill001a.lock) {} 
does not make any state transition?

I guess we could close this bug or transfer it to the
test group to fix the test case.

Fix for test case would be add Thread.sleep(1) or any other
call which makes java to vm thread state transition.

Thamnks Mingyao for looking at this problem.

-Swamy
Comments
EVALUATION This testcase used to cause crashes. See bug 4651437. Now it doesn't crash. But the way the testcase is written expects timely delivery of the async exception by Thread.stop() which isn't guaranteed by Thread.stop() API. synchronized (kill001a.lock) {} kill001a.notKilled++; In this case, the async exception isn't delivered right after the synchronized (kill001a.lock) {} statement. We've been struggling with Thread.stop() for long. We used to deliver Thread.stop() too aggressively. Now we deliver them less aggressively, which may in certain cases delay the delivery indefinitely, although in practice, it's very unlikely to happen (transition state to VM from Java, upcall java and so on will get the async exception delivered). And even a long delay is much better than a crash. ###@###.### 2003-06-16 Now 4881469 was fixed. In reality, even when an async exception wasn't delievered synchronously under very rare circumstances, it should be delievered at the next vm/native -> java state transition, which is very reasonably timely. It should definitely be delievered no later than the next safepoint. The testcase makes bad assumption. Close as not a bug. ###@###.### 2003-11-17
17-11-2003