Sorry for the delay. I tested a bit around, unfortunately this bug doesn't happen all the time. It looks like it can also happen when disconnecting just one screen.
I have filed a ticket: https://bugs.openjdk.java.net/browse/JDK-8283401 Also one time the JVM crashed, leaving a hs_err_pid file, which I attached as well. -- Marius Gesendet: Mittwoch, 23. Februar 2022 um 23:54 Uhr Von: "Kevin Rushforth" <kevin.rushfo...@oracle.com> An: "Marius Hanl" <mariush...@web.de>, "openjfx-dev" <openjfx-dev@openjdk.java.net> Betreff: Re: ArrayIndexOutOfBoundsException when disconnecting screen 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] [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 References 1. https://bugs.openjdk.java.net/browse/JDK-8239589
