-
Bug
-
Resolution: Fixed
-
P2
-
6
A member of the HotSpot client compiler collaborative research team at the Johannes Kepler University in Linz has tracked down misbehavior of the SPECjvm98 applet under some circumstances to a bug in the native code for WListPeer.getMaxWidth(). The analysis is below. I have verified that this is a bug and that it is present in the current Mustang sources. It isn't completely clear that this is the root cause of all of the rendering problems with SPECjvm98 but it definitely needs to be fixed. The fix should be backported at least to a 5.0 update release.
------
Date: Mon, 16 Jan 2006 13:50:13 +0100
Wrom: GVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNV
Subject: Bug in AWT-List
To: c1cr <###@###.###>
Reply-to: ###@###.###
Hi
In the last conference call, we discussed the problem that the SPECjvm98-GUI
is corrupted when running with a debug build of jvm.dll, but not corrupted
with a fast_debug build. In short, I think that the problem is a bug in the
native Windows implementation of the AWT-class List:
In the file "awt_List.cpp", the method
"Java_sun_awt_windows_WListPeer_getMaxWidth" should call the method
"AwtList::_getMaxWidth", but currently it calls the method
"AwtList::_UpdateMaxItemWidth".
Here is my (quite long) analysis of the problem:
I could reduce the problem to the following short program:
public static void main(String args[]) {
Frame frame = new Frame("Test");
frame.setLayout(new BorderLayout());
frame.add(BorderLayout.WEST, new List());
frame.add(BorderLayout.CENTER, new TextArea());
frame.pack();
frame.setVisible(true);
}
When you run it with a fast_debug jvm.dll, the List and the TextArea are
both shown side by side. With a debug jvm.dll, the width of the List is much
bigger than the width of the Frame, so the TextArea is not visible at all.
The method frame.pack() computes the preferred size of the List. This ends
up in a call of WListPeer.preferredSize(int v). The preferred size is
computed using the font metrics, but then the width is modified in the
following line
d.width = Math.max(d.width, getMaxWidth() + 20);
that calls the native method getMaxWidth(), implemented in the file
"awt_List.cpp" in the method "Java_sun_awt_windows_WListPeer_getMaxWidth".
In this method, there seems to be a bug: This method indirectly calls the
method "AwtList::_UpdateMaxItemWidth", but I think it should rather call
"AwtList::_getMaxWidth".
"AwtList::_UpdateMaxItemWidth" is a void method, but because of some type
casts, the return value is casted to an int and returned by the native
method. So the random current value of EAX is returned, which depends on the
kind of jvm.dll used. When using the fast_debug jvm.dll, this return value
is always 0, while it is a random high number when using the debug jvm.dll.
This leads to the width of the List being too big.
Because I do not have an environment setup to build the entire JDK including
the native libraries, I cannot verify if this is really the root of the
problem, so I hope that you can reproduce and fix this problem.
Regards
Christian
------
Date: Mon, 16 Jan 2006 13:50:13 +0100
Wrom: GVCJVTLBXFGGMEPYOQKEDOTWFAOBUZXUWLSZLKBRNV
Subject: Bug in AWT-List
To: c1cr <###@###.###>
Reply-to: ###@###.###
Hi
In the last conference call, we discussed the problem that the SPECjvm98-GUI
is corrupted when running with a debug build of jvm.dll, but not corrupted
with a fast_debug build. In short, I think that the problem is a bug in the
native Windows implementation of the AWT-class List:
In the file "awt_List.cpp", the method
"Java_sun_awt_windows_WListPeer_getMaxWidth" should call the method
"AwtList::_getMaxWidth", but currently it calls the method
"AwtList::_UpdateMaxItemWidth".
Here is my (quite long) analysis of the problem:
I could reduce the problem to the following short program:
public static void main(String args[]) {
Frame frame = new Frame("Test");
frame.setLayout(new BorderLayout());
frame.add(BorderLayout.WEST, new List());
frame.add(BorderLayout.CENTER, new TextArea());
frame.pack();
frame.setVisible(true);
}
When you run it with a fast_debug jvm.dll, the List and the TextArea are
both shown side by side. With a debug jvm.dll, the width of the List is much
bigger than the width of the Frame, so the TextArea is not visible at all.
The method frame.pack() computes the preferred size of the List. This ends
up in a call of WListPeer.preferredSize(int v). The preferred size is
computed using the font metrics, but then the width is modified in the
following line
d.width = Math.max(d.width, getMaxWidth() + 20);
that calls the native method getMaxWidth(), implemented in the file
"awt_List.cpp" in the method "Java_sun_awt_windows_WListPeer_getMaxWidth".
In this method, there seems to be a bug: This method indirectly calls the
method "AwtList::_UpdateMaxItemWidth", but I think it should rather call
"AwtList::_getMaxWidth".
"AwtList::_UpdateMaxItemWidth" is a void method, but because of some type
casts, the return value is casted to an int and returned by the native
method. So the random current value of EAX is returned, which depends on the
kind of jvm.dll used. When using the fast_debug jvm.dll, this return value
is always 0, while it is a random high number when using the debug jvm.dll.
This leads to the width of the List being too big.
Because I do not have an environment setup to build the entire JDK including
the native libraries, I cannot verify if this is really the root of the
problem, so I hope that you can reproduce and fix this problem.
Regards
Christian
- relates to
-
JDK-8050970 The behavior of java.awt.List in jdk5 should be the same to that in JDK6,7 and 8
- Resolved