United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6853592 VM test nsk.regression.b4261880 fails with "X Error of failed request: BadWindow" inconsistently.
JDK-6853592 : VM test nsk.regression.b4261880 fails with "X Error of failed request: BadWindow" inconsistently.

Details
Type:
Bug
Submit Date:
2009-06-22
Status:
Resolved
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2009-10-14
Component:
client-libs
OS:
generic
Sub-Component:
java.awt
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:

Related Reports
Backport:
Relates:

Sub Tasks

Description
The attached test fails with message:
-->/net/vmsqe.russia/export/jdk/re/7/promoted/ea/b60/binaries//solaris-i586/bin/java nsk.regression.b4261880.b4261880
X Error of failed request:  BadWindow (invalid Window parameter)
  Major opcode of failed request:  20 (X_GetProperty)
  Resource id in failed request:  0x4000011
  Serial number of failed request:  2485
  Current serial number in output stream:  2485

java -version:
/net/vmsqe.russia/export/jdk/re/7/promoted/ea/b60/binaries//solaris-i586/bin/java -version
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b60)
Java HotSpot(TM) Server VM (build 16.0-b03, mixed mode)

There severeal attempts could be needed to reproduce it.
Test
	nsk/regression/b4261880
(This was  added to allow vmsqe-scripts to find out this test.)

                                    

Comments
EVALUATION

The BadWindow error comes from the following code

------------------------------------------------------------------------------
XDnDDropTargetProtocol class - isProtocolSupported method:

int status = wpg1.execute(XErrorHandler.IgnoreBadWindowHandler.getInstance());
------------------------------------------------------------------------------


The error is expected and shouldn't be printed to console unless
someone specifies -Dsun.awt.noisyerrorhandler=true

AWT uninstalls own error handler (re-installs the default error handler)
in a VM shutdown hook but the toolkit thread is a daemon thread and
it's still alive after the VM shutdown hook have been proceesed.
Thus, any X11 error coming during shutdown will fall into the default
error handler and may cause terminating the application.
                                     
2009-09-08
EVALUATION

This problem is only reproducible after the fix for 6678385.
                                     
2009-09-28
SUGGESTED FIX

http://sa.sfbay.sun.com/projects/awt_data/7/6853592/
                                     
2009-09-30
EVALUATION

AWT have a VM shutdown hook on X11. The hook uninstalls our custom error handler and install the default error handler. The behaviour of the default error handler - upon an error it prints a message and exits. The expected AWT behaviour would be smoothly handle the error and print a message only if "noisyerrorhandler" property is specified.

This might be surprising why any Xlib routines executed after the VM hook. But this is actually expected behaviour as JVM shuts down in response to when the last non-daemon thread exits. The AWT toolkit thread is daemon thread and the thread will be terminated at some indeterminate time.

The suggested fix for the problem is to exclude the XSetErrorHandler call from the VM hook. I haven't found any violation of the XSetErrorHandler spec for the change. Another option would be forcibly terminate the toolkit thread forcibly but it doesn't look like a safe change.
                                     
2009-09-30



Hardware and Software, Engineered to Work Together