On Thu, 3 Oct 2024 09:35:51 GMT, Lukasz Kostyra <lkost...@openjdk.org> wrote:
> Contrary to issue description, the problem was not because we referenced a
> texture after it was freed, but we referenced an RTT that we just tried to
> allocate and failed to do so because of lack of space in Prism's vram pool.
> In case of attached `WebViewAnimationTest.java` test app, the problem exists
> because WebView tries to allocate a new RTT for newly opened WebView scene
> and the Prism pool does not have 16MB needed while previous WebView is still
> being displayed. Only after the old WebView is disposed of, then the RTT
> allocation can proceed and WebView can continue as normal.
>
> I looked around and did not find other solution than adding the null-checks
> to silence the NPE being thrown. NPE was originally in `RTImage.java`,
> however after adding a null check there triggered another NPE in
> `WCGraphicsPrismContext.java`, so I also added another null check there.
> Upper layers of web module seem to handle those just fine, the NPEs
> disappeared after that and the test still works properly once the pool gets
> enough room to display.
>
> All of our tests run fine with this change (I do not expect any major
> regressions, as this happens only with a very limited memory pool scenario -
> it was extremely hard and time consuming to trigger this bug on the test app
> with default 512MB pool limit). For the test app, it might take a couple
> frames until the old WebView is disposed of and there is enough room for new
> WebView's RTT in the pool, after that the scene renders properly.
I played around with testing this issue a bit and I couldn't find a good
automatic solution. The main problem here is that the exception we're looking
for is caught by the RenderJob thread, so we can't really easily capture it via
system tests. On the other hand, since it depends on Prism's vram pool, it is
quite difficult to make it happen via unit tests. I also had issues creating a
stressful enough scenario for the Web engine that would trigger the exception,
and the file attached to the issue - `ngrams.html` - uses an external
JavaScript library and a lot of additional code that I am not sure of when it
comes to its source.
In the process I also found another exception, this one thrown inside Prism:
java.lang.NullPointerException: Cannot invoke
"com.sun.prism.d3d.D3DRTTexture.contentsUseful()" because "rtt" is null
at
javafx.graphics@24-internal/com.sun.prism.d3d.D3DResourceFactory.createPresentable(D3DResourceFactory.java:383)
at
javafx.graphics@24-internal/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:81)
at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)
at
javafx.graphics@24-internal/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at
javafx.graphics@24-internal/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:126)
at java.base/java.lang.Thread.run(Thread.java:1570)
Another side effect of not properly null-checking the data we allocate, this
time in PresentingPainter. However, since it is a separate module, I think I
would solve this separately (and, again, it is very very hard to hit it in
"normal" conditions - it only appeared when vram pool was limited to 40M).
-------------
PR Comment: https://git.openjdk.org/jfx/pull/1590#issuecomment-2399757449
