JDK-6860088 : many tests failed related to AWT-EventQueue or X11 since jdk7 b60
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: solaris
  • CPU: generic
  • Submitted: 2009-07-14
  • Updated: 2011-01-19
  • Resolved: 2009-12-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Relates :  
Relates :  
Description
Many tests failed beginning jdk7 b60 (not sure if it's related to the fix of x11 robot bug 6799099 in b60). A note from QA is that the tests only failed when running on *.UTF-8 locales.

1. Download and extract the attached test.tar
2. Run test on various OSes such as Solaris 10 5/09 (update 7) x86  or SPARC by command "java DialogTest"
3. Click on "Show Dialog" and a test dialog will pop up with test characters in title, label, and button.

If you run the test on Solaris 10 8/07 (update 4) on x86 or Solaris 10 5/08 (update 5) amd64 version or OpenSolaris x86 (many also others), then the test crashes after you click on "Show Dialog". The tar file also included a crash log file.

There are many tests in i18n GS-MS test suite that fails due to the same problem (test dialog doesn't pop up).

Test suite ws: /net/sqenfs-1.sfbay.sun.com/export1/comp/jsn/all_workspace/7_int/i18n/src/GS-MS/{awt,swing}

Tests failed:

    *  swing/Swing_ar_LAF_JFrame
    * swing/Swing_ar_LAF_JDialog
    * swing/Swing_ar_SansSerif_BoldItalic_16_JTextField
    *

    * swing/Swing_de_AttributedString
    * swing/Swing_de_LAF_JDialog
    * swing/Swing_de_JFormattedTextField
    * awt/AWT_de_FrameRenderTest
    * awt/AWT_de_DialogRenderTest
    * awt/AWT_de_FrameTest
    * awt/AWT_de_DialogTest
    * awt/AWT_de_FrameTest2
    *

    * swing/Swing_hi_AttributedString
    * swing/Swing_hi_LAF_JDialog
    * swing/Swing_hi_DialogInput_BoldItalic_12_JTabbedPane
    * swing/Swing_hi_SansSerif_Italic_24_JTextField
    *

    * swing/Swing_ja_LAF_JFrame
    * swing/Swing_ja_LAF_JDialog
    * swing/Swing_ja_JFormattedTextField
    * awt/AWT_ja_FrameRenderTest
    * awt/AWT_ja_DialogRenderTest
    * awt/AWT_ja_FrameTest
    * awt/AWT_ja_DialogTest
    *

    * swing/Swing_ko_LAF_JFrame
    * swing/Swing_ko_LAF_JDialog
    * swing/Swing_ko_JFormattedTextField
    * awt/AWT_ko_FrameRenderTest
    * awt/AWT_ko_DialogRenderTest
    * awt/AWT_ko_FrameTest
    * awt/AWT_ko_DialogTest
    *

    * swing/Swing_th_AttributedString
    * swing/Swing_th_LAF_JFrame
    * swing/Swing_th_LAF_JDialog
    *

    * swing/Swing_zh_CN_LAF_JDialog
    * awt/AWT_zh_CN_FrameRenderTest
    * awt/AWT_zh_CN_DialogRenderTest
    * awt/AWT_zh_CN_FrameTest
    * awt/AWT_zh_CN_DialogTest
    *

    * swing/Swing_zh_TW_LAF_JFrame
    * swing/Swing_zh_TW_LAF_JDialog
    * awt/AWT_zh_TW_FrameRenderTest
    * awt/AWT_zh_TW_DialogRenderTest
    * awt/AWT_zh_TW_FrameTest
    * awt/AWT_zh_TW_DialogTest
    * awt/AWT_zh_TW_FrameTest2
    * awt/AWT_zh_TW_DialogTest2
    *

    * swing/Swing_zh_HK_LAF_JFrame
    * swing/Swing_zh_HK_LAF_JDialog
    * swing/Swing_zh_HK_Serif_Italic_48_JTextArea
    * swing/Swing_zh_HK_Dialog_BoldItalic_24_JSpinner
    * awt/AWT_zh_HK_FrameRenderTest
    * awt/AWT_zh_HK_DialogRenderTest
    * awt/AWT_zh_HK_FrameTest
    * awt/AWT_zh_HK_DialogTest

Comments
EVALUATION Verified the source tree and the change is already there: see the java.awt.Component class. Closing this CR as not reproducible.
08-12-2009

EVALUATION The issue is not reproducible with the awt source tree and we tried swing tree instead and got crash there. Then I found the difference between these trees (it limited by five changesets from awt side) and finally located the cure-ing diff: +++ b/src/share/classes/java/awt/Component.java Thu Aug 27 17:04:47 2009 +0400 @@ -9572,6 +9572,13 @@ public abstract class Component implemen return comp.getPeer(); } } + // traversing the hierarchy up to the closest HW container; + // further traversing may return a component that is not actually + // a native sibling of this component and this kind of z-order + // request may not be allowed by the underlying system (6852051). + if (!cont.isLightweight()) { + break; + } indexAbove = cont.getSiblingIndexAbove(); cont = cont.getContainer(); I didn't get reasons why that fixes the problem clearly. That CR6852051 addresses problems which were introduced in b55 and b60.
09-09-2009

EVALUATION As an experiment I removed the call of the Java_sun_awt_X11_XToolkit_getNumberOfButtonsImpl method and the problem still reproducible. Then I tracked the change history and updated the workspace to the 1176 revision which don't have already mentioned fix for 6834474. In that revision defect isn't reproducible and I see the dialog on the screen. For now I don't see how that http://sa.sfbay.sun.com/projects/i18n_data/7/6834474/ could affect this scenario.
29-07-2009

EVALUATION During the 6799099 the getNumButtons() has moved from within awt_Robot.c to the XToolkit.c but with missed AWT_LOCK/UNLOCK() wrap. But I just tried to get them back to the code but the problem persists.
21-07-2009

EVALUATION The code where the stack trace is shown is entered only if we are looking at a font which is for a non-latin 1 locale, as referenced by its XLFD encoding in the fontconfig.properties file and it doesn't have embedded bitmaps. UTF-8 locales are more likely to trigger that. The specific code in question in X11 that SEGVs (?) is names = XListFonts(awt_display, xlfd, 3, &count); XFreeFontNames(names); So long as we pass in valid arguments that should be fine and I see no problem here. So there's perhaps a MT issue. This specific code has been there unchanged since early JDK 1.5 builds in 2003, and it is wrapped in AWT_LOCK. Its possible some other code isn't grabbing it. I tried using "-Dsun.awt.noisyerrorhandler=true" but I am not getting a problem or a crash .. I do see by inspection that the b60 fix for 6799099 added a change in XToolkit.c and Java_sun_awt_X11_XToolkit_getNumberOfButtonsImpl makes X11 calls without (so far as I can see) grabbing the lock. I suspect it believes it is because that its synchronising the method] on the object which is the lock : In the webrev I see 1432 private native synchronized int getNumberOfButtonsImpl(); Hmm but the native code declares the 2nd arg to be a class variable JNIEXPORT jint JNICALL Java_sun_awt_X11_XToolkit_getNumberOfButtonsImpl (JNIEnv * env, jobject cls){ .. which is because the lock object is actually a class. So at first glance its a missing "static". But the class here is sun/awt/x11/XToolkit and the AWT_LOCK is actually its superclass "sun.awt.SunToolkit" .. So that wouldn't work anyway. Passing to AWT for consideration of the above.
16-07-2009

EVALUATION I went through the list of AWT bugs fixed in b60 and it's unlikely that any of the AWT bugs caused the problem. Also the problem is specific to *.UTF-8 locales (I can reproduce the problem on zh_TW.UTF-8 locale only). Build 60 includes major changes in time zone area (6834474) and the crash can be a possible side effect of these changes. The crash happens in font related code owned by Java2D team. Can Java2D team take a look at the issue please?
16-07-2009

EVALUATION Below is the stack trace from the log file provided by the submitter Stack: [0xcd9ee000,0xcda3e000], sp=0xcda3cda8, free space=13bcda3e000k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0xcd99cc76 C [libX11.so.4+0x1b90f] _XReply+0x3b7 C [libX11.so.4+0x2b20b] XListFonts+0xb3 C [libmawt.so+0x1c4df] AWTCountFonts+0x63 C [libfontmanager.so+0x7780] Java_sun_font_NativeFont_haveBitmapFonts+0x68 j sun.font.NativeFont.haveBitmapFonts([B)Z+0 j sun.font.NativeFont.hasExternalBitmaps(Ljava/lang/String;)Z+73 j sun.font.TrueTypeFont.checkUseNatives()Z+199 j sun.font.FileFont.createStrike(Lsun/font/FontStrikeDesc;)Lsun/font/FontStrike;+8 j sun.font.Font2D.getStrike(Lsun/font/FontStrikeDesc;Z)Lsun/font/FontStrike;+105 j sun.font.Font2D.getStrike(Lsun/font/FontStrikeDesc;)Lsun/font/FontStrike;+3 j sun.font.CompositeStrike.getStrikeForSlot(I)Lsun/font/PhysicalStrike;+23 j sun.font.CompositeStrike.getFontMetrics()Lsun/font/StrikeMetrics;+31 j sun.font.FontDesignMetrics.initMatrixAndMetrics()V+28 j sun.font.FontDesignMetrics.<init>(Ljava/awt/Font;Ljava/awt/font/FontRenderContext;)V+62 j sun.font.FontDesignMetrics.getMetrics(Ljava/awt/Font;Ljava/awt/font/FontRenderContext;)Lsun/font/FontDesignMetrics;+120 j sun.font.FontDesignMetrics.getMetrics(Ljava/awt/Font;)Lsun/font/FontDesignMetrics;+4 j sun.awt.X11.XComponentPeer.getFontMetrics(Ljava/awt/Font;)Ljava/awt/FontMetrics;+38 j sun.awt.X11.XButtonPeer.getMinimumSize()Ljava/awt/Dimension;+5 j sun.awt.X11.XComponentPeer.getPreferredSize()Ljava/awt/Dimension;+1 j java.awt.Component.preferredSize()Ljava/awt/Dimension;+42 j java.awt.Component.getPreferredSize()Ljava/awt/Dimension;+1 j java.awt.FlowLayout.preferredLayoutSize(Ljava/awt/Container;)Ljava/awt/Dimension;+66 j java.awt.Container.preferredSize()Ljava/awt/Dimension;+43 j java.awt.Container.getPreferredSize()Ljava/awt/Dimension;+1 j java.awt.BorderLayout.layoutContainer(Ljava/awt/Container;)V+159 j java.awt.Container.layout()V+11 j java.awt.Container.doLayout()V+1 j java.awt.Container.validateTree()V+34 j java.awt.Container.validate()V+61 j java.awt.Dialog.conditionalShow(Ljava/awt/Component;Ljava/util/concurrent/atomic/AtomicLong;)Z+24 j java.awt.Dialog.show()V+15 j java.awt.Component.show(Z)V+5 j java.awt.Component.setVisible(Z)V+2 j java.awt.Window.setVisible(Z)V+2 j java.awt.Dialog.setVisible(Z)V+2 j DialogTest$2.actionPerformed(Ljava/awt/event/ActionEvent;)V+55 j java.awt.Button.processActionEvent(Ljava/awt/event/ActionEvent;)V+11 j java.awt.Button.processEvent(Ljava/awt/AWTEvent;)V+12 j java.awt.Component.dispatchEventImpl(Ljava/awt/AWTEvent;)V+588 j java.awt.Component.dispatchEvent(Ljava/awt/AWTEvent;)V+2 j java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+46 j java.awt.EventDispatchThread.pumpOneEventForFilters(I)Z+240 j java.awt.EventDispatchThread.pumpEventsForFilter(ILjava/awt/Conditional;Ljava/awt/EventFilter;)V+30 j java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+11 j java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4 j java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3 j java.awt.EventDispatchThread.run()V+9 v ~StubRoutines::call_stub V [libjvm.so+0xb484e] V [libjvm.so+0xb4687] V [libjvm.so+0xb4667] V [libjvm.so+0xc1d07] V [libjvm.so+0xc1c39] V [libjvm.so+0xc1bb8] V [libjvm.so+0xc19f5] V [libjvm.so+0xc1998] V [libjvm.so+0x3c3639] C [libc.so.1+0xa4672] C [libc.so.1+0xa4960]
14-07-2009