United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6818464 TEST_BUG: java/util/Timer/KillThread.java failing intermittently
JDK-6818464 : TEST_BUG: java/util/Timer/KillThread.java failing intermittently

Details
Type:
Bug
Submit Date:
2009-03-17
Status:
Closed
Updated Date:
2013-12-17
Project Name:
JDK
Resolved Date:
2012-05-07
Component:
core-libs
OS:
generic
Sub-Component:
java.util
CPU:
generic
Priority:
P5
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:

Sub Tasks

Description
Tests with insufficient hardcoded timeouts that fail on slow machines (sparc) in slow configurations (Xcomp/server/fastdebug) as a result:

   java/util/Timer/KillThread.java

                                    

Comments
SUGGESTED FIX

diff --git a/test/java/util/Timer/KillThread.java b/test/java/util/Timer/KillThread.java
--- a/test/java/util/Timer/KillThread.java
+++ b/test/java/util/Timer/KillThread.java
@@ -31,19 +31,23 @@
 import java.util.*;
 
 public class KillThread {
+    static boolean waiting = true ;
     public static void main (String[] args) throws Exception  {
         Timer t = new Timer();
 
         // Start a mean event that kills the timer thread
         t.schedule(new TimerTask() {
             public void run() {
+		waiting = false ;
                 throw new ThreadDeath();
             }
         }, 0);
 
         // Wait for mean event to do the deed and thread to die.
         try {
+	    do {
             Thread.sleep(100);
+	    } while(waiting);
         } catch(InterruptedException e) {
         }
                                     
2011-11-07
EVALUATION

These timing bugs should be split into separate bugs.

In the case of KillThread there appears to be a legitimate race condition
in the test code that presumes 100 milliseconds will be sufficient to schedule 
and fire the initial TimerTask before the second schedule operation is attempted.
This could be addressed with a local variable to ensure the firect operation 
is complete.

In the second example for StoreDeadLock, the presumption is the external 
test harness will terminate the test if it does not complete in the expected
timeframe. That can be handled simply by using the timefactor for the 
test harness as a whole.
                                     
2011-11-07



Hardware and Software, Engineered to Work Together