On 27.05.16 22:17, Phil Race wrote:
I suppose this will pass on the various platforms and pipelines since
we've only seen the bug reported against xrender ? ....
Long time ago we had the similar issues on other platforms:
https://bugs.openjdk.java.net/browse/JDK-7112642
So I assume that it should not fail on all configurations(tested
ogl/xrender+linux/osx). But I intentionally added more draw operations
and didn't restrict the test on Xrender pipeline, on each platform
default will be selected and tested.
41 * @bug 8158072
I think you should also include 7172749 on this line.
updated:
http://cr.openjdk.java.net/~serb/8158072/webrev.01
On 05/27/2016 11:47 AM, Sergey Bylokhov wrote:
Hello.
Please review the new test for jdk9.
To me the reason of JDK-7172749 [1] falling was curious. So I decided
to dig into it.
To reproduce the bug the next sequence is necessary:
Thread A
- create the surface
- SG2D is created for the surface
- SG2D.drawLine is called
- XRRenderer(Pipe).drawLine is called
- ========= STOP "THREAD A" for a nanoseconds=========
Thread B
- SG2D is created for the surface create in Thread A
- SG2D.drawLine is called or any other draw operations.
- The surface is flushed.
Thread A
- ========= RUN "THREAD A" again=========
- (we still inside XRRenderer(Pipe).drawLine)
- SG2D.getCompClip() is called, and this caused revalidation of SG2D,
because it was already flushed. This means that the surface/pipes etc
are changed, but note we still in the old XRRenderer(PixelDrawPipe)
which actually should be disposed as well
- we try to use the new surface and got ClassCastException.
- After the fix we will start to draw the line again from
"SG2D.drawLine" above, using new surface and the new PixelDrawPipe.
The interesting thing is how we will work if revalidation will replace
the surface to the same type(so ClassCastException will not occurred)
but the pipe will be changed to the new? I cannot prove it but it
seems that we will draw something to the new surface using the old
PixelDrawPipe. (But this is only for the record if someone will work
on this/or similar issues).
And the test which reproduce the bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-8158072
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8158072/webrev.00
[1] https://bugs.openjdk.java.net/browse/JDK-7172749
--
Best regards, Sergey.
