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.
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.
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.
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.
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.
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
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.