JVM Crash on monitor changes

[akoch-yatta]

While playing around with the ControlExample I was able to get a JVM crash. All I needed to do is drag the shell as fast as possible between two monitors

# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffbc5136e4d, pid=48724, tid=40368
#
# JRE version: OpenJDK Runtime Environment (23.0.1+11) (build 23.0.1+11-39)
# Java VM: OpenJDK 64-Bit Server VM (23.0.1+11-39, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# C  [swt-win32-4968r4.dll+0x76e4d]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\akoch\eclipse\platform-sdk\git\eclipse.platform.swt\examples\org.eclipse.swt.examples\hs_err_pid48724.log
[21.190s][warning][os] Loading hsdis library failed
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
[0124/102633.433:ERROR:window_impl.cc(121)] Failed to unregister class Chrome_WidgetWin_0. Error = 1412

[akoch-yatta]

Dump for the crash: hs_err_pid48724.txt

It happens in ImageHandle::getImageData while doing a OS.MoveMemory

[fedejeanne]

I was able to reproduce it on master (currently eclipse-platform/eclipse.platform.swt@009532c) but not on eclipse-platform/eclipse.platform.swt@5aeb924). I'm going to try bisecting it.

[fedejeanne]

The result is:

ffa10849c52645026eb96daca7a8194d48017abb is the first bad commit
commit ffa10849c52645026eb96daca7a8194d48017abb
Author: Heiko Klare <heiko.klare@vector.com>
Date:   Wed Jan 15 10:41:21 2025 +0100

    Use AutoScaleMethod "smooth" by default for fractional scaling

    Currently, AutoScaleMethod "nearest" is used by default, leading to
    jagged image scaling results. The method "smooth" is only used on GTK
    with a fractional scaling value not being a multiple of 100.
    The reason for not using "smooth" scaling on all platform was a bug
    regarding icon transparency that has long been resolved.

    With this change, AutoScaleMethod "smooth" is used by default in
    fractional scaling scenarios (i.e., with deviceZoom not being an integer
    multiple of 100) and when using monitor-specific scaling on Windows. To
    still use "nearest" in these scenarios, it can be activated via system
    property.

 .../common/org/eclipse/swt/internal/DPIUtil.java    | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

@HeikoKlare FYI --> eclipse-platform/eclipse.platform.swt@ffa1084

[fedejeanne]

eclipse-platform/eclipse.platform.swt#1736

[fedejeanne]

Scratch that: I'm re-checking for the 3rd time and now I'm not able to reproduce the error even with the mentioned commit. I even see that the resulting autoscaleMethod is the same before and after eclipse-platform/eclipse.platform.swt@ffa1084, that is: NEAREST.

I will bisect again tomorrow.

[fedejeanne]

I even see that the resulting autoscaleMethod is the same before and after eclipse-platform/eclipse.platform.swt@ffa1084, that is: NEAREST

Wrong: it starts with NEAREST but when dragging the shell to the other monitor it changes to SMOOTH and this crashes the VM. This doesn't happen before eclipse-platform/eclipse.platform.swt@ffa1084 which means that the commit broke the functionality.

I tested with

• Params:

-Dswt.autoScale=quarter
-Dswt.autoScale.updateOnRuntime=true

• 100% monitor on the left (primary)
• 175% monitor on the right

@akoch-yatta can you please confirm that the commit caused the crash?

[HeikoKlare]

it starts with NEAREST but when dragging the shell to the other monitor it changes to SMOOTH and this crashes the VM.

That behavior is definitely not intended and unexpected. I can't see in the code how this could happen, as DPIUtil.setDeviceZoom() sets to SMOOTH when using rescaling at runtim and is already called during display initialization. Can you explain how you identified that NEAREST is used until a monitor change happens?

[fedejeanne]

Can you explain how you identified that NEAREST is used until a monitor change happens?

I added a sysout right after the field was set (in DPIUtil). Upon starting the application the value is set and then, when dragging to the other monitor, the sysout produced "SMOOTH".

FYI I am out of office for today (currently on my phone) so I will not be very responsive.

In case the regression is confirmed, I'd say this needs to be reported in an "official" issue and tagged with "regression". A solution (or a revert) should be committed before the next release.

[HeikoKlare]

Okay, I see. The auto-scaling mode is not adapted when device zoom is 100. I am not sure whether that's our intention. We should check that any maybe adapt DPIUtil.setDeviceZoom() to also enable "smooth" scaling with rescaling at runtime activated when the device zoom is 100. But let's also find out whether that's the actual cause here.

When trying to reproduce the issue, a faced another issue with the same setup that I have documented here: #226

[akoch-yatta]

I am pretty sure this one is related to #71 as well and will probably be fixed by that. I think the switch to Smooth just uncovered the bigger underlying issue.

[fedejeanne]

I am pretty sure this one is related to #71 as well and will probably be fixed by that. I think the switch to Smooth just uncovered the bigger underlying issue.

Good, I mentioned this in the official issue. I also mentioned that the issue is reproducible when the mode is always SMOOTH so we now have 2 issues to fix:

• Unintended initial state (and switch) of the auto-scale mode #227 -> I assume it should be SMOOTH from the very beginning, right @akoch-yatta ?
• VM crash when using the auto-scale method "smooth" eclipse-platform/eclipse.platform.swt#1805

[akoch-yatta]

• Unintended initial state (and switch) of the auto-scale mode #227 -> I assume it should be SMOOTH from the very beginning, right @akoch-yatta ?

I don't see a reason why it shouldn't. It shouldn't have any practical effect, I guess, but out of consistency the check for 100% doesn't really make sense to me, so I would think we should change that yes.

• VM crash when using the auto-scale method "smooth" eclipse-platform/eclipse.platform.swt#1805

Yes thats the one that should be related to #71

[HeikoKlare]

Fixed via eclipse-platform/eclipse.platform.swt#1790