JDK-5050387 : JVM crash when JOptionPane invoked in drop() method
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2004-05-20
  • Updated: 2007-07-02
  • Resolved: 2007-07-02
Related Reports
Relates :  
Description
JVM crashes when JOptionPane is displayed from the drop() method. When the drop occurs, the JOptionPane is displayed, but the JVM crashes after that. This happens only when the JOptionPane is displayed before the dropComplete() method is called. Please see the bug 4623377. The testcase attached is the same one given in the description of that bug. Please see the log also attached.

The crash is not consistent. It occurs on Solaris and Linux only with MToolkit. I was able to reproduce the problem in both the OS in 2-3 drag & drops.

Steps to reproduce:
1. Run the attached code.
2. Drag a node from the tree and drop it on the tree itself.
3. Repeat it 2-3 times and it can be seen that the JVM crashes.

Comments
EVALUATION As it is stated in the description section. The problem is an MToolkit specific issue. We are going to remove MToolkit in 7.0, and so we will not fix this particular CR. Therefor I am closing the change request.
02-07-2007

EVALUATION I have been able to reproduce the crash without the use of DGA, on both jdk5 and jdk6, only with MToolkit. (Solaris 10, JDS3) It crashes after a couple of drag/drops. It helps if instead of clicking "ok" on the appearing dialog you just hit Enter. The stack for jdk6: 3435 } 3436 3437 static void 3438 dt_notify_drop_done(JNIEnv* env, XClientMessageEvent* xclient, jboolean success, 3439 jint action) { 3440 if (xclient->message_type == XA_XdndDrop) { 3441 Display* dpy = xclient->display; 3442 XClientMessageEvent finished; 3443 long* event_data = xclient->data.l; 3444 3445 /* (dbx 9) w current thread: t@19 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xff2c0f90 [2] raise(0x6, 0x0, 0xff2a4a98, 0xffffffff, 0xff2e8284, 0x6), at 0xff25fd78 [3] abort(0xd4d7dbc8, 0x1, 0xfe05e428, 0xa83f0, 0xff2eb298, 0x0), at 0xff23ff98 [4] os::abort(0x1, 0xffd04200, 0xfef01f3c, 0xfeba7150, 0xfeee0c80, 0xfef01f3c), at 0xfe04fc90 [5] VMError::report_and_die(0x76d32, 0x76c00, 0xfef01f3c, 0xfef19c82, 0x1, 0x1), at 0xfe3c5e38 [6] report_assertion_failure(0xfeb2bc54, 0x97, 0xfeb2bc8f, 0x3d95b, 0xfeea2f50, 0x3d800), at 0xfd804c78 [7] methodOopDesc::bci_from(0xd71216a0, 0x3dd7c, 0xd71216a0, 0xfeea2f50, 0xd71216d8, 0xfeb2bc8f), at 0xfdfba188 [8] frame::interpreter_frame_bci(0x3dd7c, 0x47164, 0x753800, 0x47000, 0xfe05f6f4, 0x3dc00), at 0xfd89c4d0 [9] frame::print_on_error(0xd4d7e268, 0xd4d7e268, 0xfef278d0, 0x7d0, 0xd4d7e1b0, 0xff8af390), at 0xfd89dc94 [10] VMError::report(0xd4d7e268, 0x84980, 0xd4d7e358, 0x84800, 0x7d0, 0xfeea2f50), at 0xfe3c4944 [11] VMError::report_and_die(0xd4d7e358, 0x76cc8, 0x76c00, 0x85800, 0x85920, 0x76d00), at 0xfe3c587c [12] JVM_handle_solaris_signal(0xb, 0xffd08dea, 0x2f7000, 0x787000, 0x787000, 0xd5800084), at 0xfe05c6e0 [13] __sighndlr(0xb, 0xd4d7e7f0, 0xd4d7e538, 0xfe0571e0, 0x0, 0x1), at 0xff2bfec8 ---- called from signal handler with signal 11 (SIGSEGV) ------ =>[14] dt_notify_drop_done(env = ???, xclient = ???, success = ???, action = ???) (optimized), at 0xd5800084 (line ~3440) in "awt_dnd_dt.c" [15] Java_sun_awt_motif_X11DropTargetContextPeer_dropDone(env = ???, this = ???, nativeCtxt = ???, success = ???, action = ???) (optimized), at 0xd5800730 (line ~3575) in "awt_dnd_dt.c" [16] 0xfb0170b0(0x20000000, 0xd4d7eaec, 0xd4d7ea68, 0xffffff80, 0x0, 0x0), at 0xfb0170b0 [17] 0xfb016f70(0xf00f1128, 0x8, 0x0, 0x14, 0x0, 0xd4d7ea80), at 0xfb016f70 for jdk5 the trace is a bit different: (dbx 4) w current thread: t@15 =>[1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xff340f90 [2] raise(0x6, 0x0, 0xff324a98, 0xffffffff, 0xff368284, 0x6), at 0xff2dfd78 [3] abort(0x6800, 0x1, 0x7000, 0xa83f0, 0xff36b298, 0x0), at 0xff2bff98 [4] os::abort(0x1, 0x0, 0xfefb8cf4, 0xfef86000, 0x6f5c, 0x6c00), at 0xfee42d64 [5] VMError::report_and_die(0x0, 0xfefdec80, 0xfefd8974, 0x1, 0xfee466f4, 0xfefd8974), at 0xfeebdeb8 [6] JVM_handle_solaris_signal(0xb, 0xd297f3c0, 0xd297f108, 0x7400, 0x85e0, 0x322c78), at 0xfea6e1d0 [7] __sighndlr(0xb, 0xd297f3c0, 0xd297f108, 0xfea6d6b4, 0x0, 0x1), at 0xff33fec8 ---- called from signal handler with signal 11 (SIGSEGV) ------ [8] 0x0(0x28ef98, 0x0, 0x0, 0x8568f0, 0x856900, 0x4c), at 0x0 [9] XtPhase2Destroy(0x28ef98, 0x24, 0x0, 0x4dab08, 0x0, 0x212820), at 0xfa8b3f78 [10] _XtDoPhase2Destroy(0x2d18f8, 0x1, 0xffffffff, 0x7d38b0, 0x7d38c0, 0x1), at 0xfa8b3c7c [11] XtDispatchEvent(0x1, 0x154, 0x0, 0x2d18f8, 0xfa8e4000, 0x1), at 0xfa8ae414 [12] XtAppProcessEvent(0x2d18f8, 0x0, 0xf4240, 0x1, 0x0, 0xd297f69c), at 0xfa8b1d84 [13] 0xfb49803c(0x1, 0x59010, 0x1a, 0x68, 0xfb4f0ae8, 0xfb4f4a5c), at 0xfb49803c [14] 0xfb497874(0x322d30, 0x212820, 0x0, 0x5, 0xfb4f0ae8, 0xfb4f5910), at 0xfb497874 [15] Java_sun_awt_motif_MToolkit_run(0x322d30, 0xfe9fe5d8, 0x5946c, 0xfea7e414, 0xfb4f0ae8, 0xfefcff80), at 0xfb4976b4 [16] 0xf880c280(0x322c78, 0xd297fb0c, 0xd297fa98, 0xffffff80, 0x80000000, 0xb1c), at 0xf880c280 Since none of these have any 2D code involved, reassigning to AWT.
27-12-2006

EVALUATION Name: agR10216 Date: 06/03/2004 Committing to tiger-rc. ###@###.### 2004-06-03 ====================================================================== The hotstop error log shows dga_win_grab_common. I am able to reproduce this problem, and I always get the same stack. I wonder - what is wrong so that dga can not execute the call? Transfering to 2D for further evaluation. ###@###.### 2004-06-18 I wonder if there are two separate problems here. One is related to dga (which I can reproduce on my sparc system with ffb2 with the latest ffb patches installed), another is something else, since we don't use dga on linux, and the description mentions that the original bug is reproducible on linux as well. So far it appears that the crash on solaris is reproducible only with MToolkit. I think that the cause may be a race condition: the drawable may have been deleted by the time we attempt to grab it. It could be caused by some code which uses X not being synched on AWT_LOCK - I recall seeing a couple of places in awt code which do that. Here's the output of java_g with NOISY_AWT set: X11SD_InitWindow: widget is unrealized Xerror BadWindow (invalid Window parameter), XID 0, ser# 6310 Major opcode 20 (X_GetProperty) X11SD_InitWindow: widget is unrealized X11SD_InitWindow: widget is unrealized Xerror BadMatch (invalid parameter attributes), XID e0006e, ser# 6344 Major opcode 42 (X_SetInputFocus) Starting drag Drop Xerror BadWindow (invalid Window parameter), XID 0, ser# 7320 Major opcode 20 (X_GetProperty) X11SD_InitWindow: widget is unrealized Xerror BadWindow (invalid Window parameter), XID 0, ser# 7325 Major opcode 20 (X_GetProperty) X11SD_InitWindow: widget is unrealized X11SD_InitWindow: widget is unrealized Xerror BadMatch (invalid parameter attributes), XID e00072, ser# 7357 Major opcode 42 (X_SetInputFocus) Starting drag Drop Xerror BadWindow (invalid Window parameter), XID 0, ser# 8090 Major opcode 20 (X_GetProperty) X11SD_InitWindow: widget is unrealized Xerror BadWindow (invalid Window parameter), XID 0, ser# 8095 Major opcode 20 (X_GetProperty) X11SD_InitWindow: widget is unrealized X11SD_InitWindow: widget is unrealized Xerror BadMatch (invalid parameter attributes), XID e00076, ser# 8127 Major opcode 42 (X_SetInputFocus) Starting drag Drop Xerror BadWindow (invalid Window parameter), XID 0, ser# 8902 Major opcode 20 (X_GetProperty) X11SD_InitWindow: widget is unrealized Xerror BadWindow (invalid Window parameter), XID 0, ser# 8909 Major opcode 20 (X_GetProperty) X11SD_InitWindow: widget is unrealized X11SD_InitWindow: widget is unrealized Xerror BadMatch (invalid parameter attributes), XID e0007a, ser# 8943 Major opcode 42 (X_SetInputFocus) ## nof_mallocs = 3484, nof_frees = 1558 ## memory stomp: byte at 1e82a8 in front of object 1e82c0 ### previous object (not sure if correct): 1e77d4 (-1414812757 bytes) ### next object (not sure if correct): 1e8390 (0 bytes) # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/os.cpp:340] # # An unexpected error has been detected by HotSpot Virtual Machine: # # Internal Error (/BUILD_AREA/jdk1.5.0/hotspot/src/share/vm/runtime/os.cpp, 340 [ Patched ]), pid=25477, tid=19 # # Java VM: Java HotSpot(TM) Server VM (1.5.0-beta3-b56-debug mixed mode) # # Error: memory stomping error # An error report file with more information is saved as hs_err_pid25477.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # Current thread is 19 Dumping core ... Note that the crash is different from the one with optimized java. The stack trace: Current thread (0x00154258): JavaThread "AWT-EventQueue-0" [_thread_in_Java, id=19] Stack: [0xd2200000,0xd2280000), sp=0xd227d3a0, free space=500k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm_g.so+0xe61f24] V [libjvm_g.so+0x562bd0] V [libjvm_g.so+0xb54ed8] V [libjvm_g.so+0xb54f9c] V [libjvm_g.so+0xb556ac] V [libjvm_g.so+0x586f2c] V [libjvm_g.so+0x57b8dc] V [libjvm_g.so+0x57cf38] v blob 0xf7cac060 j java.awt.KeyboardFocusManager.getMostRecentFocusOwner(Ljava/awt/Window;)Ljava/awt/Component;+9 j java.awt.KeyboardFocusManager.clearMostRecentFocusOwner(Ljava/awt/Component;)V+60 j java.awt.Component.removeNotify()V+1 j java.awt.Container.removeNotify()V+67 j javax.swing.JComponent.removeNotify()V+1 j javax.swing.JButton.removeNotify()V+23 j java.awt.Container.removeNotify()V+38 j javax.swing.JComponent.removeNotify()V+1 j java.awt.Container.removeNotify()V+38 j javax.swing.JComponent.removeNotify()V+1 j java.awt.Container.removeNotify()V+38 j javax.swing.JComponent.removeNotify()V+1 j java.awt.Container.removeNotify()V+38 j javax.swing.JComponent.removeNotify()V+1 j java.awt.Container.removeNotify()V+38 j javax.swing.JComponent.removeNotify()V+1 j javax.swing.JRootPane.removeNotify()V+5 j java.awt.Container.removeNotify()V+38 j java.awt.Window$1DisposeAction.run()V+105 j java.awt.Window.doDispose()V+16 j java.awt.Dialog.doDispose()V+1 j java.awt.Window.dispose()V+1 j javax.swing.JOptionPane.showOptionDialog(...)I+75 ###@###.### 2004-06-21
21-06-2004