JDK-6818464 : TEST_BUG: java/util/Timer/KillThread.java failing intermittently
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util
  • Affected Version: 7
  • Priority: P5
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-03-17
  • Updated: 2013-12-17
  • Resolved: 2012-05-07
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.
7u21Fixed 8 b15Fixed
Related Reports
Relates :  
Relates :  
Tests with insufficient hardcoded timeouts that fail on slow machines (sparc) in slow configurations (Xcomp/server/fastdebug) as a result:


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) { }

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.