|
Quick Lists
|
|
Bug ID:
|
6774258
|
|
Votes
|
0
|
|
Synopsis
|
api/java_awt/Component/index.html#PaintUpdate fails randomly
|
|
Category
|
java:classes_awt
|
|
Reported Against
|
|
|
Release Fixed
|
6u12(b03)
|
|
State
|
11-Closed,
Verified,
bug
|
|
Priority:
|
2-High
|
|
Related Bugs
|
6571823
,
6593621
,
6602349
,
6741515
|
|
Submit Date
|
20-NOV-2008
|
|
Description
|
JCK : JCK 6b b24
J2SE : FAIL - jdk 6u10, 6u11 not always reproducible. (rarely fails on 6u7)
Platform[s] : FAIL - found on Windows
switch/Mode : FAIL - default
Recently we noticed that api/java_awt/Component/index.html#PaintUpdate fails sometimes with the message:
paintUpdateOnFirstShowOnScreen: Failed. Update is called on heavyweight component, however that was not requested.
paintUpdateOnFirstShowOnScreen_ZeroWidthOptimization: Passed. OKAY
paintUpdateOnFirstShowOnScreen_ZeroHeightOptimization: Passed. OKAY
repaintHeavyweight_1: Passed. OKAY
repaintLightweight_1: Passed. OKAY
repaintHeavyweight_2: Passed. OKAY
repaintLightweight_2: Passed. OKAY
repaintHeavyweight_3: Passed. OKAY
repaintLightweight_3: Passed. OKAY
repaintHeavyweight_4: Passed. OKAY
repaintLightweight_4: Passed. OKAY
testPaintAll: Passed. OKAY
Rarely other testcases may fail.
Failures occures mostly on windows. Can't say is it regression or not, since older version of java was tested with JCK6a and this test was excluded in JCK6a (See CR 6602349). There is also CR 6571823 that states that this test is invalid. The only visible changes in this test between JCK6a and JCK6b is possibility to provide other timeouts and changes in error messages.
Steps to reproduce:
1. Log in to stt-15.russia (or other windows machine)
2. Install JCK6b (on stt-15.russia it is installed to Z:/Links/stt/jck_promotions/6a/fcs/alt2/binaries/JCK-runtime-6a)
3. Install JDK 6u11 b03
4. Run the script:
#!/bin/bash -v
JAVA=C:/JDK/jdk1.6.0_10/bin/java.exe
export CLASSPATH="Z:/Links/stt/jck_promotions/6a/fcs/alt2/binaries/JCK-runtime-6a/classes"
OPTS="-Djck.EDTScript.initialDelay=1000ms -Djck.EDTScript.checkDelay=200ms"
TEST=javasoft.sqe.tests.api.java.awt.Component.PaintUpdateTests
$JAVA -version
$JAVA $TEST
Posted Date : 2008-11-20 16:02:11.0
|
|
Work Around
|
N/A
|
|
Evaluation
|
A standalone test has been attached to the report.
It looks like the issue is a regression of one of the java2d fixes in 6u10.
the problem is not reproducible using the option -Dsun.java2d.noddraw=true
The test shows a frame, the frame includes a custom HW component,
the HW component overrides the paint|update methods, AWT calls the update method
upon showing but the test doesn't expect to receive this call.
Posted Date : 2008-11-21 10:01:05.0
The stack trace of the wrong update event are
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1206)
at java.awt.EventQueue.postEvent(EventQueue.java:272)
at java.awt.EventQueue.postEventPrivate(EventQueue.java:215)
at java.awt.EventQueue.postEvent(EventQueue.java:188)
at java.awt.Component.repaint(Component.java:3038)
at java.awt.Component.repaint(Component.java:2952)
at sun.java2d.d3d.D3DScreenUpdateManager.repaintPeerTarget(D3DScreenUpdateManager.java:275)
at sun.java2d.d3d.D3DScreenUpdateManager.createScreenSurface(D3DScreenUpdateManager.java:176)
at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java:390)
at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java:365)
at sun.awt.windows.WComponentPeer.setBounds(WComponentPeer.java:147)
at java.awt.Component.reshapeNativePeer(Component.java:2083)
at java.awt.Component.reshape(Component.java:2031)
at java.awt.Component.setBounds(Component.java:1997)
at java.awt.GridLayout.layoutContainer(GridLayout.java:430)
at java.awt.Container.layout(Container.java:1398)
at java.awt.Container.doLayout(Container.java:1387)
at java.awt.Container.validateTree(Container.java:1485)
at java.awt.Container.validate(Container.java:1457)
at java.awt.Window.show(Window.java:843)
at java.awt.Component.show(Component.java:1447)
at java.awt.Component.setVisible(Component.java:1400)
at java.awt.Window.setVisible(Window.java:824)
at test.main(test.java:15)
The failure is a regression of the fix for 6593621 (fixed in 6u10 b03), commenting out the call to repaintPeerTarget() in the D3DScreenUpdateManager class eliminates the update event. It looks like the repaintPeerTarget() method shouldn't be called when the component is created.
Posted Date : 2008-11-21 13:38:55.0
The createScreenSurface method of D3DScreenUpdateManager class
calls repaint() method to make sure that the content of
the component is repainted correctly and the repaint() method
causes a call to the component's update().
The createScreenSurface calls the repaint() method upon
- the showing of the components
- the resize of the components
- display change
In all these cases AWT will invoke the update() method and
this is wrong because these operations are system-level
painting oparetation and AWT should invoke the paint() method.
Posted Date : 2008-11-21 15:28:46.0
I haven't found a work in AWT specification/painting guidelines about AWT *must not* call update() for system-triggered paint requests. That's why I consider this bug to be a regression (caused by Java2D fix for 6593621) instead of JCK failure, and would suggest correcting the corresponding JCK test. At the same time, it would be fine to have a regression test that checks for update() calls for system- and app-triggered paint requests.
Posted Date : 2008-11-21 16:30:18.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |