JDK-4648733 : HTMLTransferConsoleOutputTest and GetContentsInterruptedTest occasionally fail
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2002-03-07
  • Updated: 2002-06-17
  • Resolved: 2002-03-14
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.1 hopperFixed
Related Reports
Relates :  
JDK-4271416 - Should try to coalesce events on the PostEventQueue
Relates :  
JDK-4030718 - A program which calls Toolkit.getDefaultToolkit() won't terminate.
Relates :  
JDK-4513976 - DnDImageTest failing for between JVM scenario on Solaris 64-bit
Description

Name: dsR10078			Date: 03/07/2002

###@###.###

Regression tests java/awt/Clipboard/GetContentsInterruptedTest/GetContentsInterruptedTest.html
and java/awt/datatransfer/HTMLTransferConsoleOutputTest/HTMLTransferConsoleOutputTest.html
occasionally fail. The failures are reproducible with the current AWT
workspace sometines on Linux RH 6.1 and very rarely on Sparc/Solaris
2.7. The tests fail on timeout:

#Test Results (version 2)
#Thu Mar 07 11:35:21 MSK 2002
#checksum:199c3205d5635a55
#-----testdescription-----
$file=/.automount/aldebaran/root/export3/das/hopper/test/java/awt/Clipboard/GetContentsInterruptedTest/GetContentsInterruptedTest.html
$root=/.automount/aldebaran/root/export3/das/hopper/test/java/awt
author=###@###.### area=Clipboard
keywords=bug4532299
run=USER_SPECIFIED applet GetContentsInterruptedTest.html\n
source=GetContentsInterruptedTest.html
title=tests that getting clipboard contents on the interrupted thread will            not cause deadlock

#-----environment-----

#-----testresult-----
description=file:///.automount/aldebaran/root/export3/das/hopper/test/java/awt/Clipboard/GetContentsInterruptedTest/GetContentsInterruptedTest.html
end=Thu Mar 07 11:35:21 MSK 2002
environment=regtest
execStatus=Failed. Execution failed: Program `/net/aldebaran/export3/das/hopper/build/linux-i386/bin/java' interrupted! (timed out?)
javatestOS=Linux 2.2.12-20 (i386)
javatestVersion=2.1.6
script=com.sun.javatest.regtest.RegressionScript 
sections=script_messages build applet
start=Thu Mar 07 11:33:21 MSK 2002
status=Failed. Execution failed: Program `/net/aldebaran/export3/das/hopper/build/linux-i386/bin/java' interrupted! (timed out?)
test=Clipboard/GetContentsInterruptedTest/GetContentsInterruptedTest.html
work=/home/das/bug/b4513976/jtreg/linux/JTwork/Clipboard/GetContentsInterruptedTest

#section:script_messages
----------messages:(5/293)----------
JDK under test: (/net/aldebaran/export3/das/hopper/build/linux-i386)
java version "1.4.0-internal"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-internal-das_11_dec_2001_18_04)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b02, mixed mode)
Timeout signalled after 120.0 seconds

#section:build
----------messages:(3/113)----------
command: build GetContentsInterruptedTest 
reason: Named class compiled on demand
elapsed time (seconds): 0.0040
result: Passed. No need to compile: GetContentsInterruptedTest.java

#section:applet
----------messages:(3/155)----------
command: applet GetContentsInterruptedTest.html
reason: User specified action: run applet GetContentsInterruptedTest.html 
elapsed time (seconds): 120.066
----------System.out:(0/0)----------
----------System.err:(24/1875)----------
Mar 7, 2002 8:33:55 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 37.
Mar 7, 2002 8:33:55 AM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
Mar 7, 2002 8:33:57 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock System prefs.Unix error code 37.
Mar 7, 2002 8:33:57 AM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
Mar 7, 2002 8:34:25 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 37.
Mar 7, 2002 8:34:25 AM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
Mar 7, 2002 8:34:27 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock System prefs.Unix error code 37.
Mar 7, 2002 8:34:27 AM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
Mar 7, 2002 8:34:55 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock User prefs. Unix error code 37.
Mar 7, 2002 8:34:55 AM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
Mar 7, 2002 8:34:57 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode
WARNING: Could not lock System prefs.Unix error code 37.
Mar 7, 2002 8:34:57 AM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.
result: Failed. Execution failed: Program `/net/aldebaran/export3/das/hopper/build/linux-i386/bin/java' interrupted! (timed out?)


test result: Failed. Execution failed: Program `/net/aldebaran/export3/das/hopper/build/linux-i386/bin/java' interrupted! (timed out?)

###@###.### 2002-03-07
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper VERIFIED IN: hopper-beta
14-06-2004
WORK AROUND Name: dsR10078 Date: 03/07/2002 ======================================================================
11-06-2004
SUGGESTED FIX Name: dsR10078 Date: 03/07/2002 The event dispatch thread should process two event sources itself: the PostEventQueue and the java event queue, so after it detaches itself from the java event queue on termination it should check that both sources are empty and a new thread should started if either is not empty: --- EventDispatchThread.java Mon Feb 11 18:49:37 2002 *************** *** 15,20 **** --- 15,21 ---- import sun.security.action.GetPropertyAction; import sun.awt.DebugHelper; import sun.awt.AWTAutoShutdown; + import sun.awt.SunToolkit; /** *************** *** 118,124 **** * events are posted after this thread died all events that * currently are in the queue will never be dispatched. */ ! if (theQueue.peekEvent() != null) { theQueue.initDispatchThread(); } AWTAutoShutdown.getInstance().notifyThreadFree(this); --- 119,125 ---- * events are posted after this thread died all events that * currently are in the queue will never be dispatched. */ ! if (theQueue.peekEvent() != null || !SunToolkit.noEvents()) { theQueue.initDispatchThread(); } AWTAutoShutdown.getInstance().notifyThreadFree(this); --- SunToolkit.java Mon Feb 11 18:50:21 2002 *************** *** 298,303 **** --- 298,314 ---- } } + public static boolean noEvents() { + AppContext appContext = AppContext.getAppContext(); + PostEventQueue postEventQueue = + (PostEventQueue)appContext.get(POST_EVENT_QUEUE_KEY); + if (postEventQueue != null) { + return postEventQueue.noEvents(); + } else { + return true; + } + } + /* * Execute a chunk of code on the Java event handler thread for the * given target. Does not wait for the execution to occur before *************** *** 650,655 **** --- 661,670 ---- eventQueue = eq; } + public boolean noEvents() { + return queueHead == null; + } + /* * Continually post pending AWTEvents to the Java EventQueue. */ ###@###.### 2002-03-07 ======================================================================
07-03-2002
EVALUATION Name: dsR10078 Date: 03/07/2002 The failures depend on timings. The cause of failure is a race condition introduced with the fix for 4030718. It didn't manifest until exposed with the fix for 4513976. The AWT auto shutdown mechanism terminates the event dispatch thread when it detects that all the following conditions are true: 1.There are no non-disposed peers. 2.There are no events in the native event queue. 3.There are no events in java event queues. To terminate the event dispatch thread we post a special shutdown event to the associated event queue. The event dispatch thread terminates itself when it processes this event. On termination the event dispatch thread detaches itself from the java event queue and checks if the queue is still empty. If an event appeared on the queue, a new event dispatch thread is started for this queue. With the fix for 4271416, the PostEventQueue thread was eliminated and now the event dispatch thread should check if there are any events on the PostEventQueue and move the events from the PostEventQueue to the java event queue. So currently there are two event sources that the event dispatch thread should process itself: the associated java event queue and PostEventQueue. When an event is posted to the PostEventQueue and the java event queue doesn't have an attached event dispatch thread, a new event dispatch thread is started for the java event queue. This thread checks the PostEventQueue, moves the event to the java event queue and processes it. When the test failures happen, an event is posted to the PostEventQueue during the event dispatch thread termination, but before the event dispatch thread is detached from the event queue, so a new event dispatch thread is not started. When the event dispatch thread completes termination it verifies that the java event queue is still empty, successfully detaches itself from the event queue and terminates. At this moment there is no way for the event that resides on the PostEventQueue to be processed. For these two regression tests this event happens to be an InvocationEvent that requests the transfer data from the current Clipboard owner. The tests are designed so that no other event can occur after this InvocationEvent and trigger the initialization of a new event dispatch thread. So the request is not processed and the requestor client hangs. The hang didn't manifest without the fix for 4513976, because we used the default Xt selection timeout value (5 sec). If the owner failed to provide the transfer data within this time we reported transfer failure and in this case the tests passed. The fix for 4513976 sets the timeout value to the UINT_MAX. Xt imposes a limitation on the owner response time to guarantee that the requestor doesn't hang if the selection owner hangs. However the transfer failure will be reported even if the selection owner doesn't hang, but the data conversion requires more than 5 seconds (this happens when large images are transferred between clients). So we assume that for Java it is more appropriate to guarantee that the selection transfer succeeds if the selection owner doesn't hang, so we set a limitation to the maximum possible value. ###@###.### 2002-03-07 ======================================================================
07-03-2002