Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6373369

Bug in WListPeer.getMaxWidth()



    • b15
    • 6
    • b75
    • generic
    • generic


      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
      Subject: Bug in AWT-List
      To: c1cr <###@###.###>
      Reply-to: ###@###.###


      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

      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());

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



        Issue Links



              dcherepanov Dmitry Cherepanov
              kbr Kenneth Russell (Inactive)
              0 Vote for this issue
              0 Start watching this issue