RFR: 8280468: Crashes in getConfigColormap, getConfigVisualId, XVisualIDFromVisual on Linux

Sergey Bylokhov serb at openjdk.java.net
Mon Jan 24 18:49:10 UTC 2022


On Mon, 24 Jan 2022 07:49:30 GMT, Maxim Kartashev <duke at openjdk.java.net> wrote:

> Can you elaborate, please? Do you mean that this custom JDK would synthetically change `X11GraphicsDevice.screen` at the "right" time?

Yes, at the "right" time and the "right" number of monitors.

> > I am not sure that it is possible to synchronize access to the screen number across the code w/o introducing deadlocks, the current change does not cover all cases where the X11GraphicsDevice.screen is passed around. probably we should follow this [suggestion](https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java#L58) and everywhere the "screen" is used under the awt lock (1)check that it is less than the number of screens and use 0(main screen as a fallback), or (2) some "default value" if the number of screens is zero at that time - something similar was implemented on macOS by the [JDK-8211992](http://hg.openjdk.java.net/jdk/jdk/rev/814c49afb1a7)
> 
> I agree, returning some default as a fallback should also work. However, that's so radically different from the approach I've taken that a separate PR would be required.

It is better to start from the bug reproducing. As the change - the awt lock always should be the last one, I am not sure that wrapping a bunch of code by that lock is safe.

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

PR: https://git.openjdk.java.net/jdk/pull/7182



More information about the client-libs-dev mailing list