Phil, Sergey, Could you commit this fix into jdk9 repo (my committing rights are on only up to jdk8)
Also, we would like to have this fix backported into jdk8 because it’s a main jdk for our current products. Best Regards, Alexey > On 24 May 2016, at 11:43, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > On 24.05.16 10:21, Alexey Ushakov wrote: >> Hi Sergey, >> >>> Did you check what sequence of calls causes a situation when we have >>> BufImgSurfaceData as a surface and XRRenderer as a Pipe? >> >> No. The issue is really difficult to reproduce and it disappears with any >> logging enabled, so it might be a race condition. I was able to reproduce it >> artificially by resizing VMware VM number of times with high frequency. It >> also was reported by users on KDE desktops. > > ok, Looks fine. > >>> On 23 May 2016, at 20:11, Sergey Bylokhov <sergey.bylok...@oracle.com> >>> wrote: >>> >>> Hi, Alexey. >>> Did you check what sequence of calls causes a situation when we have >>> BufImgSurfaceData as a surface and XRRenderer as a Pipe? I thought we >>> always change them at once(actually the pipe usually updated from the >>> surface.validatePipe(SG2D))? >>> >>> On 23.05.16 17:44, Alexey Ushakov wrote: >>>> Hello Phil, >>>> >>>> Here is a small fix of quite annoying exception that we sometimes have >>>> in IDEA product. The bug is assigned to you so, please have a look. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7179454 >>>> Webrev: http://cr.openjdk.java.net/~avu/JDK-7179454/webrev.00 >>>> >>>> Sometimes rendering is performed into surface of wrong type, so we need >>>> to recreate it by throwing InvalidPipeException. The exception is caught >>>> at upper level and the surface of appropriate type is created. Similar >>>> approach is used in OpenGL and D3D pipeline. >>>> >>>> Best Regards, >>>> Alexey >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey.
