AW: Status on JDK-8305479 (+ info to reproduce it)

[Reto Merz]

Hello SWinxy

Thanks for looking at it.

I have reproduced it with the demo code from JDK-8305479
on my machine and also on a virtuale machine.

While I can reproduce it on my physical machine (Windows 2019 Server) very easily,
it is much harder on the virtual machine (Windows 11).

In our production application it is very easy to reproduce it in both environment, physical and on a virtual machine.

Yes, the WaitForSingleObject is also what we have seen when we have looked at a dump with WinDbg and a Debugimage JDK.
We have also found a solution to "detect" the freeze, but we have not found a way to unfreeze/release the lock.
What we have try for example is to call 'endComposition' on the WInputMethod instance (the instance which cause the deadlock).
Or to call 'finalize' method.

At the moment we register a custom EventQueue which does not dispatch the WInputMethod event at all.
Like this:

@Override
protected void dispatchEvent(AWTEvent event) {
    if (InvocationEvent.INVOCATION_DEFAULT == event.getID() &&
            event.paramString().startsWith("INVOCATION_DEFAULT,runnable=sun.awt.windows.WInputMethod$")) {
        return; // do not dispatch ; https://mail.openjdk.org/pipermail/client-libs-dev/2024-August/021543.html
    }
    super.dispatchEvent(event);
}

We assume that our workaround will have some bad side effects for users with IME.
But the freeze is much worse for our customers.
And we assume the bug is a regression introdcued by JDK-8261231.

Thanks

Regards
Reto



Von: SWinxy <swinxythecat at gmail.com> 
Gesendet: Mittwoch, 7. August 2024 22:17
An: Reto Merz <reto.merz at abacus.ch>
Cc: client-libs-dev at openjdk.org
Betreff: Re: Status on JDK-8305479 (+ info to reproduce it)

This appears to be a deadlock. I've been able to replicate it, but it's annoyingly finicky to get it to freeze. A thread gets stuck on WaitForSingleObject at awt_Toolkit.cpp#L3139 (in AwtToolkit::InvokeInputMethodFunction) waiting for an object to be signaled, but the signalling gets lost. And so it waits indefinitely.

dmarkov, do you know more? A possible solution would be to change the timeout to be 1000ms, but that may have unintended effects.

SWinxy

On Mon, Aug 5, 2024 at 5:23 AM Reto Merz <mailto:reto.merz at abacus.ch> wrote:
Hello,

Our customers are using Drag & Drop functionality more and more
and reports are increasing that our application is haning.
It starts to escalate since the only workaround is to restart the app right now.

The problem is already reported with JDK-8305479 [1]

Is there any way to increase the priority of that issue
or is a developer here we can hire to search for a fix (and create a pull request)?

Btw, the bug is much easier to reproduce:

1) Start the demo app (see [1])
2) try to drop a document (eg: pdf file) from the windows desktop into the textfield

Repeat step 2 if necessary. For me after 1-2 try this will cause the hang.
If not, move the JFrame to another position and repeat step 2 again.

Tested with latest JDK:
    java version "22.0.2" 2024-07-16
    Java(TM) SE Runtime Environment (build 22.0.2+9-70)
    Java HotSpot(TM) 64-Bit Server VM (build 22.0.2+9-70, mixed mode, sharing)

OS MS Windows:
    Microsoft Windows [Version 10.0.17763.5458]

Regards
Reto Merz

[1] https://bugs.openjdk.org/browse/JDK-8305479