Bug ID: JDK-4872170 Customer Java Application crashes in the XtWindowOfObject function

Type: Bug
Component: client-libs
Sub-Component: java.awt
Affected Version: 1.4.2

Priority: P2
Status: Resolved
Resolution: Fixed
OS: solaris_8
CPU: sparc

Submitted: 2003-05-30
Updated: 2003-09-05
Resolved: 2003-09-05

Other
1.4.2_02 02Fixed

Customer (Fujitsu) are doing testing of their application NETSMART with JDK 1.4.2 and see the JVM crash sometimes when they drag and drop some GUI objects. The JVM crash stack trace is always the same but the customer can not reproduce this consistently.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_02 tiger FIXED IN: 1.4.2_02 tiger INTEGRATED IN: 1.4.2_02 tiger tiger-b19

24-08-2004

SUGGESTED FIX Name: atR10251 Date: 08/27/2003 Destroying of a widget is postponed if it has owned widgets. The last owned widget being disposed will destroy its owner. ###@###.### 2003-08-27 ====================================================================== Name: atR10251 Date: 08/29/2003 This fix is safer than suggested above and moreover it follows javadoc. ------- Window.java ------- *** /tmp/sccs.t_ai40 Fry Aug 29 10:37:44 2003 --- Window.java Mon Aug 28 16:43:22 2003 *************** *** 571,576 **** --- 571,593 ---- * @see #show */ public void dispose() { + doDispose(); + } + + /* + * Fix for 4872170. + * If dispose() is called on parent then its children have to be disposed as well + * as reported in javadoc. So we need to implement this functionality even if a + * child overrides dispose() in a wrong way without calling super.dispose(). + */ + void disposeImpl() { + dispose(); + if (getPeer() != null) { + doDispose(); + } + } + + void doDispose() { class DisposeAction implements Runnable { public void run() { synchronized(ownedWindowList) { *************** *** 578,584 **** Window child = (Window) (((WeakReference) (ownedWindowList.elementAt(i))).get()); if (child != null) { ! child.dispose(); } } } --- 595,601 ---- Window child = (Window) (((WeakReference) (ownedWindowList.elementAt(i))).get()); if (child != null) { ! child.disposeImpl(); } } } ------- Dialog.java ------- *** /tmp/sccs.q9aW3 Fry Aug 29 10:37:44 2003 --- Dialog.java Mon Aug 28 16:44:30 2003 *************** *** 621,632 **** * Disposes the Dialog and then causes show() to return if it is currently * blocked. */ ! public void dispose() { ! disposeImpl(); ! } ! ! private void disposeImpl() { ! super.dispose(); hideAndDisposeHandler(); } --- 621,628 ---- * Disposes the Dialog and then causes show() to return if it is currently * blocked. */ ! void doDispose() { ! super.doDispose(); hideAndDisposeHandler(); } ###@###.### 2003-08-29 ======================================================================

29-08-2003

EVALUATION There is no test case associated with this bug, and no instructions on how to get the application the customer is using. Without one of these two things, we cannot begin investigation of this bug. Setting to incomplete until such information is provided. One further note: the customer call reports this bug against 1.4.2_01, which is probably incorrect. The comments section says 1.4.2-beta build 18. ###@###.### 2003-06-01 The customer gave a simple testcase that can reproduce the problem. Attached is a tar file with the testcase. If you look at the comments, there is a description of how to reproduce the crash. ###@###.### 2003-07-25 It appears that this bug is not related to dnd (perhaps). The instructions we originally got for reproducing it involved dragging and dropping, but the instructions in the Comments have to do with menus (not dnd). I'll assume this is somewhere in the menu code right now. Since this is an escalation, the fix will need to be forward-ported into tiger when it is fixed. ###@###.### 2003-07-25 Name: dsR10078 Date: 07/28/2003 I reproduce the crash with the following steps: - Launch testcase. - Click on the open button. - Click on the help button on the second frame. - Close the second frame ( File menu -> close ) - Drag the toolbar handle. The crash is reproducible on Sparc/Solaris 8 with JDK 1.4.2 b25 and JDK 1.5.0 b11. The cause of the crash is that when the second frame is closed, the widgets of its child dialog are destroyed, but they are not removed from AWT native structures (allTopLevel list), since this dialog overrides dispose() so that it doesn't call super.dispose(). The crash happens when we dereference a pointer to the destroyed widget in allTopLevel list. The application doesn't use the Java DnD API and the crash is not related to drag-and-drop operations. ###@###.### 2003-07-28 ====================================================================== Name: atR10251 Date: 08/27/2003 Yet more critical that when the parent's widget is disposed the child's widget is destroyed but the reference to its peer continues to exist in its Java class instance. And then if a user tries to show the child a crash will happen. This concerns Windows as well. Solution is the next. We can't destroy a widget if it has owned widgets. It's destroying has to be postponed to the moment its last child will be disposed. ###@###.### 2003-08-27 ====================================================================== Name: atR10251 Date: 08/27/2003 The last suggestion will prevent the crash but it requires changes in native code that may become a reef in the future and so they are dangerous. On the other hand javadoc states that calling dispose() on parent will dispose its children anyway. So we need to implement such a functionality that would allow us to follow javadoc even if child overrides dispose() in such a wrong way. ###@###.### 2003-08-27 ======================================================================

27-08-2003