RFR: 8352209: NPE com.sun.prism.d3d.D3DTextureData.getContext [v3]

[Lukasz Kostyra]

On Thu, 30 Oct 2025 16:48:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Also, what do you think about adding the null assignment to the ES2 pipeline?

I think it wouldn't hurt, it would be an additional safeguard. I also can't really imagine the scenario where we would drop an update that is otherwise necessary - if we do then that's a separate memory management issue, as in we freed something that we still need to use.

> A more general question: what is the condition for the release of the resource/texture? Does it come from a native call, reference count or something else? It feels like there should be a strict mechanism for this.

This is unfortunately a question I don't have a definitive answer for yet. I was looking into this yesterday after I wrote my initial comment, but it is quite difficult to trace down the exact cause.

My current running theory is that mask textures are considered to be temporary (if you look at ex. `BaseShaderGraphics.renderShape()` it gets unlocked right after adding a shape to render) and eventually - once the Pool runs out of space while processing something else - said texture can get pruned by the Pool since it is unlocked. But, the rendering call that updates it has not been submitted yet, only a quad was added by `renderShape()` to the VertexBuffer. Next time the VertexBuffer gets flushed we attempt to prepare the mask for the upcoming VertexBuffer flush and end up trying to use-after-free like I described above.

If that is indeed the case this could require a more serious fix - we would have to make sure that the mask stays locked while it is waiting in `BaseContext` for rendering so that the Pool doesn't prune it before VertexBuffer is flushed. That would probably require a more serious rework and a bunch more testing to get it right and ensure no stale references stay in the Pool. I might add this to JBS as a follow-up investigation and enhancement/rework.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1951#issuecomment-3473083887