JDK-6259344 : PIT: DnD testcase resulting in VM crash
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-04-21
  • Updated: 2011-01-19
  • Resolved: 2005-09-17
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.
JDK 6
6 b53Fixed
Related Reports
Relates :  
Relates :  
Description
This occurs only with b35 AWT PIT build. 

java -version
java version "1.6.0-awt.pit-int-jcg-win-03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-awt.pit-int-jcg-win-03-java2d_19_apr_2005_08_17)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b32, mixed mode)

Running the attached automated testcase results in VM crash on WinXP system. The testcase runs fine on b32. 

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000001, pid=576, tid=1744
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-ea-b32 mixed mode)
# Problematic frame:
# C  0x00000001
#
# An error report file with more information is saved as hs_err_pid576.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

Attached is the crash log.

###@###.### 2005-04-21 13:20:26 GMT

Comments
EVALUATION We should use TRY_NO_HANG macros instead of TRY_NO_VERIFY. TRY_NO_HANG verifies that Toolkit is still active overwise returns us to Java immediately.
05-09-2005

SUGGESTED FIX ------- awt_DnDDT.cpp ------- *** /tmp/sccs.mre01d Mon Sep 5 15:01:48 2005 --- awt_DnDDT.cpp Mon Sep 5 14:40:50 2005 *************** *** 1322,1328 **** JNIEXPORT void JNICALL Java_sun_awt_windows_WDropTargetContextPeer_dropDone(JNIEnv* env, jobject self, jlong dropTarget, jboolean success, jint actions) { ! TRY_NO_VERIFY; AwtDropTarget* pDropTarget = (AwtDropTarget*)dropTarget; --- 1322,1328 ---- JNIEXPORT void JNICALL Java_sun_awt_windows_WDropTargetContextPeer_dropDone(JNIEnv* env, jobject self, jlong dropTarget, jboolean success, jint actions) { ! TRY_NO_HANG; AwtDropTarget* pDropTarget = (AwtDropTarget*)dropTarget;
05-09-2005

EVALUATION I have added debug print in DropTaget destructor. Looks like AwtDropTarget had destructed before last invocation was made. The invocation of DropTarget->DropDone() brought us to the exception. Z:\bugs\6259344>J:\bin\java.exe bug_4710511 Test passed! AwtDropTarget was distracted.# # An unexpected error has been detected by HotSpot Virtual Machine: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000001, pid=864, tid=732 # # Java VM: Java HotSpot(TM) Client VM (1.6.0-ea-b43 mixed mode) # Problematic frame: # C 0x00000001 # # An error report file with more information is saved as hs_err_pid864.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp #
02-09-2005

EVALUATION The problem is difficult to reproduce. I could reproduce the problem ones or twice. After it I should reboot PC. Looks like the root of the issue is DropDonePtr structure.
01-09-2005

WORK AROUND Inserting some delay between last robot.mouseRelease() and System.exit() eliminates the problem. ###@###.### 2005-06-20 09:27:45 GMT
20-06-2005

EVALUATION The crash always happens while system is shutdowning, i. e. after the test had passed and System.exit(...) has been called. The problem is probably that we are trying to access some of the native objects from WDropTargetContextPeer.dropDone() and in the same time are disposing them from another thread. Some synchronization should be added (AwtToolkit::SyncCall or something like that). ###@###.### 2005-06-17 08:17:55 GMT
17-06-2005

SUGGESTED FIX ###@###.### 2005-06-20 09:27:45 GMT
17-06-2005