-
Bug
-
Resolution: Duplicate
-
P4
-
None
-
1.1.5
-
sparc
-
solaris_2.5.1
Name: mf23781 Date: 12/15/97
I know addNotify() shouldn't be called by user code, but it is
public, and its use shouldn't crash the JVM.
Most of the AWT classes (eg TextArea) are written with the assumption
that the peer has not yet been created:
/**
* Creates the TextArea's peer. The peer allows us to modify
* the appearance of the TextArea without changing any of its
* functionality.
*/
public void addNotify() {
peer = getToolkit().createTextArea(this);
super.addNotify();
}
If this has already been called (such as by a user's program)
then the first peer is orphaned, and a new peer is put in
its place. The problem is that this orphaned peer is garbage collected,
but doesn't have a finalize method to clean up the
physical system resources, i.e. the X widgets. Hence, you get
X widgets floating around, and each of these X widgets is set up
to do a callback when it gets an event. The callback is set up
with the address of the peer. When that event eventually comes
(in this case, an Expose event, when part of an old X widget is
uncovered), it passes the address of the peer to the callback
function. But the peer has been long since garbage collected,
so it points to garbage, hence the problem.
One solution (now used on AIX) is to change all the addNotify methods so
they only create a new peer if a peer has not already been created.
Like this:
/**
* Creates the TextArea's peer. The peer allows us to modify
* the appearance of the TextArea without changing any of its
* functionality.
*/
public void addNotify() {
if (peer == null)
peer = getToolkit().createTextArea(this);
super.addNotify();
}
Some AWT classes already have this check, but there are plenty
that don't. This solution is not thread safe, but it seems like
the best option at the moment.
This problem occurred in a large custmer app, so we haven't got
a small testcase, but hopefully this description is sufficient to
understand the problem. They were calling addNotify() on a TextArea
after a resize, so after the window had been resized lots of times,
one of the orphaned peers got an expose event, causing the crash.
======================================================================
- duplicates
-
JDK-4091443 gratuitous use of addNotify() causes memory leaks and potential crashes
-
- Closed
-