[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: ArrayIndexOutOfBoundsException when disconnecting screen
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2022-02-23 22:54:14
Message-ID: 6a09f4fa-3b05-21a3-d14e-66f8a8a0a463 () oracle ! com
[Download RAW message or body]

I spent a fair bit of time simulating and testing the 
D3DERR_DEVICEREMOVED cases for RDP disconnect to fix JDK-8239589 [1], 
but detaching a screen, which will change the number of active adapters, 
is a somewhat different case (I'm not sure how easy it would be to 
simulate it). It's very likely that it isn't handled in a robust manner. 
Do you know whether you need to disconnect 2 screens to reproduce this, 
or would disconnecting a single external monitor cause it?

Based on the stack trace, it looks like the D3DResourceFactory array has 
been recreated with the reduced number of adapters (1), but the old 
screen is still being used by the instance of PPSRenderer.

Can you file a bug with the stack trace, and as much information about 
how to reproduce it as you can.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8239589


On 2/23/2022 3:35 AM, Marius Hanl wrote:
>     I get an ArrayIndexOutOfBoundsException sometimes when I disconnect my
>     screen(s).
>     Setup: I have a laptop with a docking station attached. The docking
>     station is connected to two screen, so when I disconnect it 2 screen
>     will be 'lost'.
>
>     The following stacktrace is visible and the application is completely
>     black and unresponsive:
>     java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for
>     length 1
>         at
>     com.sun.prism.d3d.D3DPipeline.getD3DResourceFactory(D3DPipeline.java:21
>     7)
>         at
>     com.sun.prism.d3d.D3DPipeline.getResourceFactory(D3DPipeline.java:284)
>         at
>     com.sun.scenario.effect.impl.prism.ps.PPSRenderer.validate(PPSRenderer.
>     java:101)
>         at
>     com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PP
>     SRenderer.java:221)
>         at
>     com.sun.scenario.effect.impl.prism.ps.PPSRenderer.getCompatibleImage(PP
>     SRenderer.java:67)
>         at
>     com.sun.scenario.effect.Effect.getCompatibleImage(Effect.java:479)
>         at
>     com.sun.javafx.sg.prism.NodeEffectInput.getImageDataForBoundedNode(Node
>     EffectInput.java:228)
>         at
>     com.sun.javafx.sg.prism.NodeEffectInput.filter(NodeEffectInput.java:131
>     )
>         at
>     com.sun.scenario.effect.FilterEffect.filter(FilterEffect.java:185)
>         at com.sun.scenario.effect.Offset.filter(Offset.java:160)
>         at com.sun.scenario.effect.Merge.filter(Merge.java:148)
>         at
>     com.sun.scenario.effect.DelegateEffect.filter(DelegateEffect.java:70)
>         at
>     com.sun.scenario.effect.impl.prism.PrEffectHelper.render(PrEffectHelper
>     .java:166)
>         at
>     com.sun.javafx.sg.prism.EffectFilter.render(EffectFilter.java:61)
>         at com.sun.javafx.sg.prism.NGNode.renderEffect(NGNode.java:2384)
>         at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2069)
>         at com.sun.javafx.sg.prism.NGNode.render(NGNode.java:1964)
>         at com.sun.javafx.sg.prism.NGGroup.renderContent(NGGroup.java:270)
>         at
>     com.sun.javafx.sg.prism.NGRegion.renderContent(NGRegion.java:579)
>         at com.sun.javafx.sg.prism.NGNode.doRender(NGNode.java:2072)
>         ... ( a lot of doRender(..), renderContent(..) calls... )
>         at
>     com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:480)
>         at
>     com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:329)
>         at
>     com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:
>     92)
>         at
>     java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors
>     .java:515)
>         at
>     java.base/java.util.concurrent.FutureTask.runAndReset$$$capture(FutureT
>     ask.java:305)
>         at
>     java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java)
>         at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
>         at
>     java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolE
>     xecutor.java:1128)
>         at
>     java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPool
>     Executor.java:628)
>         at
>     com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumR
>     enderer.java:126)
>         at java.base/java.lang.Thread.run(Thread.java:829)
>
>     -----------------------------------------------------------------------
>     -------------------------------------------------------
>
>     Now my question:
>     A naive fix would be an array check here but does someone has more
>     information about the code here?
>     And more interesting: Is there a way to write tests for this? Maybe
>     with simulating/faking screens and then 'faking' a screen disconnect?
>
>     -- Marius

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic