xxxxx@xxxxx  

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=  xxxxx@xxxxx   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?)

  xxxxx@xxxxx   2002-03-07
======================================================================

======================================================================

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.

  xxxxx@xxxxx   2002-03-07
======================================================================