Re: OpenJdk11-28-EA JDialog hanging

[Sergey Bylokhov]

Hi, Laurent.


Sergey, would it be possible to ask for a backport to 11.0.2 release, even if 
RDP is passed since october 28th.
Could you motivate the urgency, like a P1 according to me for ITW ?


I am not sure that it is possible, at least before that it should be ported to 
11u.


--
Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Dear Martin,

Congratulations 🥂, you fixed that really tricky issue !!

Sergey, would it be possible to ask for a backport to 11.0.2 release, even
if RDP is passed since october 28th.
Could you motivate the urgency, like a P1 according to me for ITW ?

Salute,
Laurent

Le jeu. 15 nov. 2018 à 06:28, Krishna Addepalli <
krishna.addepa...@oracle.com> a écrit :

> Hi Martin & Laurent,
>
> Thank you for all your efforts in root causing and fixing this important
> issue.
>
> Regards,
> Krishna
>
> > On 14-Nov-2018, at 11:16 PM, Martin Balao  wrote:
> >
> > Hi,
> >
> > Submit-repo tests passed.
> >
> > Changeset has been committed:
> > http://hg.openjdk.java.net/jdk/jdk/rev/08a0bf1592bd
> >
> > Thanks to all of you for your time reviewing this.
> >
> > I'll now propose a JDK-11 backport.
> >
> > Kind regards,
> > Martin.-
>
>

Re: OpenJdk11-28-EA JDialog hanging

[Krishna Addepalli]

Hi Martin & Laurent,

Thank you for all your efforts in root causing and fixing this important issue.

Regards,
Krishna

> On 14-Nov-2018, at 11:16 PM, Martin Balao  wrote:
> 
> Hi,
> 
> Submit-repo tests passed.
> 
> Changeset has been committed:
> http://hg.openjdk.java.net/jdk/jdk/rev/08a0bf1592bd
> 
> Thanks to all of you for your time reviewing this.
> 
> I'll now propose a JDK-11 backport.
> 
> Kind regards,
> Martin.-

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi,

Submit-repo tests passed.

Changeset has been committed:
http://hg.openjdk.java.net/jdk/jdk/rev/08a0bf1592bd

Thanks to all of you for your time reviewing this.

I'll now propose a JDK-11 backport.

Kind regards,
Martin.-

Re: OpenJdk11-28-EA JDialog hanging

[Krishna Addepalli]

+1

 

Krishna

 

From: Laurent Bourgès  
Sent: Tuesday, November 13, 2018 2:18 PM
To: Martin Balao 
Cc: awt-dev@openjdk.java.net
Subject: Re:  OpenJdk11-28-EA JDialog hanging

 

Hi,

Sergey approved the webrev.4, anyone else?

 

I would like this bug fix to be pushed soon, then this RFR.

 

Regards,

Laurent

 

Le ven. 9 nov. 2018 à 14:50, Laurent Bourgès mailto:bourges.laur...@gmail.com"bourges.laur...@gmail.com> a écrit :

Dear Martin & Sergey,

 

I just tested webrev.03 on latest openjdk12 and it passed my tests: good job !

(I am not an official openjdk reviewer)

 

Le ven. 9 nov. 2018 à 14:43, Martin Balao mailto:mba...@redhat.com"mba...@redhat.com> a écrit :

Hi,

Here we have Webrev.04:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04/
 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.zip

 

I suppose the Webrev.04 only removed the SequencedEventTest class ?
 

@Sergey: are you okay to go?

 

I hope too.

 

Sergey, could you handle the backport process to JDK11u, please ?

 

Cheers,

Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Sergey Bylokhov]

It looks fine, I have run internal tests jck/regression
and no new issues were found.

Thank you for contribution.

On 13/11/2018 10:24, Martin Balao wrote:

Sergey,

Are we okay to go with Webrev.04?

Thanks,
Martin.-

On Tue, Nov 13, 2018 at 5:47 AM, Laurent Bourgès
 wrote:

Hi,
Sergey approved the webrev.4, anyone else?

I would like this bug fix to be pushed soon, then this RFR.

Regards,
Laurent

Le ven. 9 nov. 2018 à 14:50, Laurent Bourgès  a
écrit :


Dear Martin & Sergey,

I just tested webrev.03 on latest openjdk12 and it passed my tests: good
job !
(I am not an official openjdk reviewer)

Le ven. 9 nov. 2018 à 14:43, Martin Balao  a écrit :


Hi,

Here we have Webrev.04:

  * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04/
  *
http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.zip



I suppose the Webrev.04 only removed the SequencedEventTest class ?



@Sergey: are you okay to go?



I hope too.

Sergey, could you handle the backport process to JDK11u, please ?

Cheers,
Laurent



--
Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Sergey,

Are we okay to go with Webrev.04?

Thanks,
Martin.-

On Tue, Nov 13, 2018 at 5:47 AM, Laurent Bourgès
 wrote:
> Hi,
> Sergey approved the webrev.4, anyone else?
>
> I would like this bug fix to be pushed soon, then this RFR.
>
> Regards,
> Laurent
>
> Le ven. 9 nov. 2018 à 14:50, Laurent Bourgès  a
> écrit :
>>
>> Dear Martin & Sergey,
>>
>> I just tested webrev.03 on latest openjdk12 and it passed my tests: good
>> job !
>> (I am not an official openjdk reviewer)
>>
>> Le ven. 9 nov. 2018 à 14:43, Martin Balao  a écrit :
>>>
>>> Hi,
>>>
>>> Here we have Webrev.04:
>>>
>>>  * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04/
>>>  *
>>> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.zip
>>>
>>
>> I suppose the Webrev.04 only removed the SequencedEventTest class ?
>>
>>>
>>> @Sergey: are you okay to go?
>>
>>
>> I hope too.
>>
>> Sergey, could you handle the backport process to JDK11u, please ?
>>
>> Cheers,
>> Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi,
Sergey approved the webrev.4, anyone else?

I would like this bug fix to be pushed soon, then this RFR.

Regards,
Laurent

Le ven. 9 nov. 2018 à 14:50, Laurent Bourgès  a
écrit :

> Dear Martin & Sergey,
>
> I just tested webrev.03 on latest openjdk12 and it passed my tests: good
> job !
> (I am not an official openjdk reviewer)
>
> Le ven. 9 nov. 2018 à 14:43, Martin Balao  a écrit :
>
>> Hi,
>>
>> Here we have Webrev.04:
>>
>>  * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04/
>>  *
>> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.zip
>>
>>
> I suppose the Webrev.04 only removed the SequencedEventTest class ?
>
>
>> @Sergey: are you okay to go?
>>
>
> I hope too.
>
> Sergey, could you handle the backport process to JDK11u, please ?
>
> Cheers,
> Laurent
>

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

On Fri, Nov 9, 2018 at 10:50 AM, Laurent Bourgès
 wrote:
>
> I suppose the Webrev.04 only removed the SequencedEventTest class ?
>

That's right

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Dear Martin & Sergey,

I just tested webrev.03 on latest openjdk12 and it passed my tests: good
job !
(I am not an official openjdk reviewer)

Le ven. 9 nov. 2018 à 14:43, Martin Balao  a écrit :

> Hi,
>
> Here we have Webrev.04:
>
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04/
>  *
> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.zip
>
>
I suppose the Webrev.04 only removed the SequencedEventTest class ?


> @Sergey: are you okay to go?
>

I hope too.

Sergey, could you handle the backport process to JDK11u, please ?

Cheers,
Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi,

Here we have Webrev.04:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04/
 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.04.zip

@Sergey: are you okay to go?

Thanks,
Martin.-

On Thu, Nov 8, 2018 at 9:09 PM, Sergey Bylokhov
 wrote:
> I am fine with that.
>
>> So, I suggest to remove this test and keep both Laurent's anyour test.
>
>
>
> --
> Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Sergey Bylokhov]

I am fine with that.


So, I suggest to remove this test and keep both Laurent's anyour test.



--
Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Sergey,

What the test is doing does not look right to me.

An event whose source app context is associated with "system" thread
group is being posted on the EventQueue of an app context associated
to "TestThreadGroup" thread group. See
"Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(new
ActionEvent(this, 0, null));" and
"Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(new
ActionEvent(this, 1, null));" lines. Apparently, if you get the
EventQueue and post directly as the test is doing
("Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(...)"),
no checks are done in this regard. However, if you use
SunToolkit.postEvent API to post the event, this is checked and an
exception thrown.

The reason why this test is now failing is that the event is re-posted
through SunToolkit.postEvent API in SequencedEvent class. Even though
it would be possible to modify Webrev.03 to use the EventQueue
directly -and bypass the check-, I actually think that this check is
good. So, I suggest to remove this test and keep both Laurent's and
your test.

What do you think?

Thanks,
Martin.-



On Mon, Nov 5, 2018 at 5:01 PM, Sergey Bylokhov
 wrote:
> Hi, Martin.
>
> Can you please recheck the test which was created for JDK-8152974
> http://hg.openjdk.java.net/jdk/jdk/rev/719064f540f3
> It started to fail after this version of the fix.
>
>>   * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.03/
>
>  BTW I have run all our internal tests on this version of the fix, and still
> waiting of the results.
>
>
> --
> Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Sergey Bylokhov]

Hi, Martin.

Can you please recheck the test which was created for JDK-8152974
http://hg.openjdk.java.net/jdk/jdk/rev/719064f540f3
It started to fail after this version of the fix.


  * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.03/
 
BTW I have run all our internal tests on this version of the fix, and still waiting of the results.



--
Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Even though I'm still not convinced about the need of imposing partial
order sync on asynchronous events, we can do it.

Here it's Webrev.03 that includes partial ordering of non-SequencedEvent
events and Sergey's unit test:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.03/
 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.03.zip

I've put Sergey's unit test into a bash-loop and reached 300+ iterations
without any issues. Laurent's functional test is also passing. Laurent's
unit test (not included here) does not pass for the reasons already
discussed.

Kind regards,
Martin.-

On Wed, Oct 31, 2018 at 1:13 PM, Sergey Bylokhov  wrote:

> Hi, Martin.
> On 31/10/2018 09:03, Martin Balao wrote:
>
>> Your MultipleContextsUnitTest test has 2 assertions that don't look good
>> to me:
>>
>>   * dispatchSENumber < num1
>>   * dispatchSENumber < num2
>>
>> My understanding is that these assertions mean that a non-SequencedEvent
>> event is expected to be synchronized with SequencedEvent events. If such
>> synchronization is needed, the event has to be wrapped in a SequencedEvent
>> event. There are no guarantees otherwise; previous to my proposal these
>> event were discarded and in my Webrev.02 they are dispatched asynchronously.
>>
>
> This is not a strong synchronization, it is just an expectation that the
> events which were posted after SequencedEvent should be dispatched after
> it. So if the app will have focus event and then mouse click, then mouse
> click should be dispatched after the focus. Note that the for this case the
> test does not check the exact sequence of order(==), just a relative
> order(<).
>
>
> --
> Best regards, Sergey.
>

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,

Le mer. 31 oct. 2018 à 17:03, Martin Balao  a écrit :

> Hi Sergey,
>
> Your MultipleContextsUnitTest test has 2 assertions that don't look good
> to me:
>
>  * dispatchSENumber < num1
>  * dispatchSENumber < num2
>
> My understanding is that these assertions mean that a non-SequencedEvent
> event is expected to be synchronized with SequencedEvent events. If such
> synchronization is needed, the event has to be wrapped in a SequencedEvent
> event. There are no guarantees otherwise; previous to my proposal these
> event were discarded and in my Webrev.02 they are dispatched asynchronously.
>

I think Sergey approach makes sense as awt events should happen on the
proper window...

>
> I've tried your test -without these assertions- against my Webrev.02 and
> it passes, as well as Laurent's 1st and 2nd test.
>

Thanks for your tests, could you try Sergey's patch too ?
As I am on holidays, I did not have to test Sergey's patch, maybe tonight.

I am really happy that this bug is going to be fixed soon, by either Martin
or Sergey patch.

Cheers,
Laurent


> Kind regards,
> Martin.-
>
>
> On Mon, Oct 29, 2018 at 3:06 PM, Sergey Bylokhov <
> sergey.bylok...@oracle.com> wrote:
>
>> Hi, Martin.
>> Thank you for this details description of the problem, I have tried to
>> summarize it in this test, which should fail on all platforms:
>>
>>
>> http://cr.openjdk.java.net/~serb/8204142/webrev.00/raw_files/new/test/jdk/java/awt/event/SequencedEvent/MultipleContextsUnitTest.java
>>
>> It creates a number of SequencedEvents and post them in a different
>> orders. It also has some additional checks, for example InvocationEvent
>> posted in between of SequencedEvents should be dispatched in the same order
>> as posted/ or posted not early that SequencedEvents. Some new checks might
>> be added.
>>
>> Here is another version of the fix which tries to resolve the problem
>> covered by the test above:
>> http://cr.openjdk.java.net/~serb/8204142/webrev.00/
>>
>> But I have run it for a night in a bash loop, and it failed after 100+
>> iterations. So there is some room for improvements.
>>
>> Note that this fix should be applied on top of JDK-8211435:
>> http://cr.openjdk.java.net/~serb/8211435/webrev.00/
>>
>>
>> On 26/10/2018 15:25, Martin Balao wrote:
>>
>>>
>>> If you are talking about an example from this message:
>>>
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014426.html
>>> >> >
>>>
>>>
>>> That's only the first half of this issue, which is indeed easy to fix by
>>> just dispatching SentEvent events. The second half is here:
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014436.html
>>>
>>
>>
>>
>> --
>> Best regards, Sergey.
>>
>
>

Re: OpenJdk11-28-EA JDialog hanging

[Sergey Bylokhov]

Hi, Martin.
On 31/10/2018 09:03, Martin Balao wrote:

Your MultipleContextsUnitTest test has 2 assertions that don't look good to me:

  * dispatchSENumber < num1
  * dispatchSENumber < num2

My understanding is that these assertions mean that a non-SequencedEvent event 
is expected to be synchronized with SequencedEvent events. If such 
synchronization is needed, the event has to be wrapped in a SequencedEvent 
event. There are no guarantees otherwise; previous to my proposal these event 
were discarded and in my Webrev.02 they are dispatched asynchronously.


This is not a strong synchronization, it is just an expectation that the events 
which were posted after SequencedEvent should be dispatched after it. So if the 
app will have focus event and then mouse click, then mouse click should be 
dispatched after the focus. Note that the for this case the test does not check 
the exact sequence of order(==), just a relative order(<).


--
Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Sergey,

Your MultipleContextsUnitTest test has 2 assertions that don't look good to
me:

 * dispatchSENumber < num1
 * dispatchSENumber < num2

My understanding is that these assertions mean that a non-SequencedEvent
event is expected to be synchronized with SequencedEvent events. If such
synchronization is needed, the event has to be wrapped in a SequencedEvent
event. There are no guarantees otherwise; previous to my proposal these
event were discarded and in my Webrev.02 they are dispatched asynchronously.

I've tried your test -without these assertions- against my Webrev.02 and it
passes, as well as Laurent's 1st and 2nd test.

Kind regards,
Martin.-


On Mon, Oct 29, 2018 at 3:06 PM, Sergey Bylokhov  wrote:

> Hi, Martin.
> Thank you for this details description of the problem, I have tried to
> summarize it in this test, which should fail on all platforms:
>
> http://cr.openjdk.java.net/~serb/8204142/webrev.00/raw_files
> /new/test/jdk/java/awt/event/SequencedEvent/MultipleContextsUnitTest.java
>
> It creates a number of SequencedEvents and post them in a different
> orders. It also has some additional checks, for example InvocationEvent
> posted in between of SequencedEvents should be dispatched in the same order
> as posted/ or posted not early that SequencedEvents. Some new checks might
> be added.
>
> Here is another version of the fix which tries to resolve the problem
> covered by the test above:
> http://cr.openjdk.java.net/~serb/8204142/webrev.00/
>
> But I have run it for a night in a bash loop, and it failed after 100+
> iterations. So there is some room for improvements.
>
> Note that this fix should be applied on top of JDK-8211435:
> http://cr.openjdk.java.net/~serb/8211435/webrev.00/
>
>
> On 26/10/2018 15:25, Martin Balao wrote:
>
>>
>> If you are talking about an example from this message:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/
>> 014426.html > /014426.html>
>>
>>
>> That's only the first half of this issue, which is indeed easy to fix by
>> just dispatching SentEvent events. The second half is here:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014436.html
>>
>
>
>
> --
> Best regards, Sergey.
>

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Sergey,

Le lun. 29 oct. 2018 à 19:06, Sergey Bylokhov 
a écrit :

> Hi, Martin.
> Thank you for this details description of the problem, I have tried to
> summarize it in this test, which should fail on all platforms:
>
>
> http://cr.openjdk.java.net/~serb/8204142/webrev.00/raw_files/new/test/jdk/java/awt/event/SequencedEvent/MultipleContextsUnitTest.java
>
> It creates a number of SequencedEvents and post them in a different
> orders. It also has some additional checks, for example InvocationEvent
> posted in between of SequencedEvents should be dispatched in the same order
> as posted/ or posted not early that SequencedEvents. Some new checks might
> be added.
>

It looks close to my initial reproducer test:
http://mail.openjdk.java.net/pipermail/awt-dev/2018-September/014276.html

It was "blocking" immediately on jdk11.


> Here is another version of the fix which tries to resolve the problem
> covered by the test above:
> http://cr.openjdk.java.net/~serb/8204142/webrev.00/
>
> But I have run it for a night in a bash loop, and it failed after 100+
> iterations. So there is some room for improvements.
>

I will test your patch with my 2 test variants.

Thank you for your new proposal,
Laurent


> Note that this fix should be applied on top of JDK-8211435:
> http://cr.openjdk.java.net/~serb/8211435/webrev.00/
>
>
> On 26/10/2018 15:25, Martin Balao wrote:
> >
> > If you are talking about an example from this message:
> >
> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014426.html <
> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014426.html>
> >
> >
> > That's only the first half of this issue, which is indeed easy to fix by
> just dispatching SentEvent events. The second half is here:
> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014436.html
>
>
>
> --
> Best regards, Sergey.
>

Re: OpenJdk11-28-EA JDialog hanging

[Sergey Bylokhov]

Hi, Martin.
Thank you for this details description of the problem, I have tried to 
summarize it in this test, which should fail on all platforms:

http://cr.openjdk.java.net/~serb/8204142/webrev.00/raw_files/new/test/jdk/java/awt/event/SequencedEvent/MultipleContextsUnitTest.java

It creates a number of SequencedEvents and post them in a different orders. It 
also has some additional checks, for example InvocationEvent posted in between 
of SequencedEvents should be dispatched in the same order as posted/ or posted 
not early that SequencedEvents. Some new checks might be added.

Here is another version of the fix which tries to resolve the problem covered 
by the test above:
http://cr.openjdk.java.net/~serb/8204142/webrev.00/

But I have run it for a night in a bash loop, and it failed after 100+ 
iterations. So there is some room for improvements.

Note that this fix should be applied on top of JDK-8211435:
http://cr.openjdk.java.net/~serb/8211435/webrev.00/


On 26/10/2018 15:25, Martin Balao wrote:


If you are talking about an example from this message:
http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014426.html 



That's only the first half of this issue, which is indeed easy to fix by just 
dispatching SentEvent events. The second half is here: 
http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014436.html




--
Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi,

Digging a bit into SequencedEvent event clients, I've found 3 usages:

 1) Wrapping focus in and out window events (Unix only)
 2) Wrapping TimedWindowEvent events (Windows and macOS only)
 3) Wrapping FocusEvent events in
XEmbedChildProxyPeer.simulateMotifRequestFocus (Unix only)

This is how case #1 works in Linux:

There is a single thread retrieving all X11 events, called AWT-XAWT. This
thread is turning raw X11 events into more generic/high-level ones and
posting them to different EDT queues (depending on the event target). Works
as a demultiplexer. In particular, FOCUS-IN and FOCUS-OUT events may be
sent to different target windows and dispatched by different EDTs.
Synchronization is needed because otherwise the sequence order may be
broken. Let's assume that AWT-XAWT gets a FOCUS-OUT to window B first and
FOCUS-IN to window A then. EDTs can be scheduled so that a FOCUS-IN sent to
window A is dispatched before a FOCUS-OUT to windows B. This execution does
not represent what really happened. What we want, at the end of the day, is
synchronizing window listeners across different EDTs with focus
transitions. I don't see how receiving asynchronous events
(non-SequencedEvent events) in-between would be different than receiving
them after a transition to a no-focus (FOCUS-OUT and no FOCUS-IN received).
What are the concerns regarding dispatching non-Sequenced events while
waiting?

@Denis: looks to me that a single ordered list matters here. Events are
already synchronized if we look into single EventQueues. The problem is
synchronizing through multiple EventQueues and multiple EDTs (which is a
Java abstraction).

Kind regards,
Martin.-



On Fri, Oct 26, 2018 at 12:11 PM, Denis Fokin  wrote:

> Hi guys,
>
> just out of curiosity, should not we store the SE lists per-AppContext?
>
> Thank you,
>Denis
>
> On Fri, Oct 26, 2018 at 1:35 AM Krishna Addepalli <
> krishna.addepa...@oracle.com> wrote:
>
>> Hi Sergey,
>>
>> I also agree with Laurent about root cause of hang provided by Martin.
>> However, we just need to make sure that non Sequenced Events are not
>> dispatched when SequencedEvents are being dealt with.
>>
>> Thanks,
>> Krishna
>>
>>
>> On 25-Oct-2018, at 1:35 PM, Laurent Bourgès 
>> wrote:
>>
>> Hi Sergey & Martin,
>>
>>
>>> > AWT experts, what do you advice about asynchronous events: to Block or
>>> to dispatch selected awt events...
>>>
>>> I think that before answer this question we need to clarify why the
>>> current code hangs.
>>>
>>
>> According to me, Martin already exposed his detailled analysis of 2 cases
>> making AWT to hang with several AppContexts: in summary, like a deadlock,
>> the EDT threads are waiting for each other to dispatch SequencedEvents !
>>
>> Please Martin correct me, or maybe give us an updated diagnostic of the
>> problem ?
>>
>> This thread is already quite long and both Martin & me invested a lot of
>> time on debugging, fixing & testing, please give us your understanding,
>> Sergey.
>>
>> Finally I am in favor of Martin's patch 2 sent by Oct 16th:
>> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02
>>
>> Cheers,
>> Laurent
>>
>>
>>

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

On Fri, Oct 26, 2018 at 6:59 PM, Sergey Bylokhov  wrote:

> On 25/10/2018 01:05, Laurent Bourgès wrote:
>
>> According to me, Martin already exposed his detailled analysis of 2 cases
>> making AWT to hang with several AppContexts: in summary, like a deadlock,
>> the EDT threads are waiting for each other to dispatch SequencedEvents !
>>
>
> If you are talking about an example from this message:
> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014426.html
>
>
That's only the first half of this issue, which is indeed easy to fix by
just dispatching SentEvent events. The second half is here:
http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014436.html

Re: OpenJdk11-28-EA JDialog hanging

[Sergey Bylokhov]

On 25/10/2018 01:05, Laurent Bourgès wrote:

According to me, Martin already exposed his detailled analysis of 2 cases 
making AWT to hang with several AppContexts: in summary, like a deadlock, the 
EDT threads are waiting for each other to dispatch SequencedEvents !


If you are talking about an example from this message:
http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014426.html

Then pay attention that it describes not a deadlock, but another situation. It 
has 4 events, one of them is dispatched in correct order(because it was created 
first), but others are not dispatched because they are not wakeup by the 
dispatched event. To me it looks like the bug is in the 
SequencedEvent.dispose() method, which should wakeup EDT where the next event 
should be dispatched.
Maybe it is possible to create/post a dummy WakeupEvent which will use 
SequencedEvent.ID and be used to wakeup the EDT?


Take a look to the test which was added in JDK-8152974:
http://hg.openjdk.java.net/jdk/jdk/rev/719064f540f3

This test creates a number of SequencedEvents and posts them in a different 
order to one/to many apcontexts, all of them are dispatched in the right order. 
I think it should be possible to create a new test based on the test above, 
which will fail on all platforms.


--
Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Denis Fokin]

Hi guys,

just out of curiosity, should not we store the SE lists per-AppContext?

Thank you,
   Denis

On Fri, Oct 26, 2018 at 1:35 AM Krishna Addepalli <
krishna.addepa...@oracle.com> wrote:

> Hi Sergey,
>
> I also agree with Laurent about root cause of hang provided by Martin.
> However, we just need to make sure that non Sequenced Events are not
> dispatched when SequencedEvents are being dealt with.
>
> Thanks,
> Krishna
>
>
> On 25-Oct-2018, at 1:35 PM, Laurent Bourgès 
> wrote:
>
> Hi Sergey & Martin,
>
>
>> > AWT experts, what do you advice about asynchronous events: to Block or
>> to dispatch selected awt events...
>>
>> I think that before answer this question we need to clarify why the
>> current code hangs.
>>
>
> According to me, Martin already exposed his detailled analysis of 2 cases
> making AWT to hang with several AppContexts: in summary, like a deadlock,
> the EDT threads are waiting for each other to dispatch SequencedEvents !
>
> Please Martin correct me, or maybe give us an updated diagnostic of the
> problem ?
>
> This thread is already quite long and both Martin & me invested a lot of
> time on debugging, fixing & testing, please give us your understanding,
> Sergey.
>
> Finally I am in favor of Martin's patch 2 sent by Oct 16th:
> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02
>
> Cheers,
> Laurent
>
>
>

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Yes, I think we now have a good understanding of why this hangs.

The remaining discussion, in my opinion, is if we should block or not while
handling SequencedEvents. I'd like to see strong arguments on both sides to
get this right. Even though my original position was for not-blocking -for
the reasons already shared-, I acknowledge that a deeper investigation is
needed and will do it as soon as possible.

On Thu, Oct 25, 2018 at 11:40 AM, Mario Torre  wrote:

> I'm not a reviewer, but FWIW I concur with the analysis and with the
> proposed solution.
>
> Cheers,
> Mario
> On Thu, Oct 25, 2018 at 10:05 AM Laurent Bourgès
>  wrote:
> >
> > Hi Sergey & Martin,
> >
> >>
> >> > AWT experts, what do you advice about asynchronous events: to Block
> or to dispatch selected awt events...
> >>
> >> I think that before answer this question we need to clarify why the
> current code hangs.
> >
> >
> > According to me, Martin already exposed his detailled analysis of 2
> cases making AWT to hang with several AppContexts: in summary, like a
> deadlock, the EDT threads are waiting for each other to dispatch
> SequencedEvents !
> >
> > Please Martin correct me, or maybe give us an updated diagnostic of the
> problem ?
> >
> > This thread is already quite long and both Martin & me invested a lot of
> time on debugging, fixing & testing, please give us your understanding,
> Sergey.
> >
> > Finally I am in favor of Martin's patch 2 sent by Oct 16th:
> > http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02
> >
> > Cheers,
> > Laurent
>
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH 
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

Re: OpenJdk11-28-EA JDialog hanging

[Mario Torre]

I'm not a reviewer, but FWIW I concur with the analysis and with the
proposed solution.

Cheers,
Mario
On Thu, Oct 25, 2018 at 10:05 AM Laurent Bourgès
 wrote:
>
> Hi Sergey & Martin,
>
>>
>> > AWT experts, what do you advice about asynchronous events: to Block or to 
>> > dispatch selected awt events...
>>
>> I think that before answer this question we need to clarify why the current 
>> code hangs.
>
>
> According to me, Martin already exposed his detailled analysis of 2 cases 
> making AWT to hang with several AppContexts: in summary, like a deadlock, the 
> EDT threads are waiting for each other to dispatch SequencedEvents !
>
> Please Martin correct me, or maybe give us an updated diagnostic of the 
> problem ?
>
> This thread is already quite long and both Martin & me invested a lot of time 
> on debugging, fixing & testing, please give us your understanding, Sergey.
>
> Finally I am in favor of Martin's patch 2 sent by Oct 16th:
> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02
>
> Cheers,
> Laurent



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

Re: OpenJdk11-28-EA JDialog hanging

[Krishna Addepalli]

Hi Sergey,

I also agree with Laurent about root cause of hang provided by Martin.
However, we just need to make sure that non Sequenced Events are not dispatched 
when SequencedEvents are being dealt with.

Thanks,
Krishna

> On 25-Oct-2018, at 1:35 PM, Laurent Bourgès  wrote:
> 
> Hi Sergey & Martin,
> 
> 
> > AWT experts, what do you advice about asynchronous events: to Block or to 
> > dispatch selected awt events...
> 
> I think that before answer this question we need to clarify why the current 
> code hangs.
> 
> According to me, Martin already exposed his detailled analysis of 2 cases 
> making AWT to hang with several AppContexts: in summary, like a deadlock, the 
> EDT threads are waiting for each other to dispatch SequencedEvents !
> 
> Please Martin correct me, or maybe give us an updated diagnostic of the 
> problem ?
> 
> This thread is already quite long and both Martin & me invested a lot of time 
> on debugging, fixing & testing, please give us your understanding, Sergey.
> 
> Finally I am in favor of Martin's patch 2 sent by Oct 16th:
> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02 
> 
> 
> Cheers,
> Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Sergey & Martin,


> > AWT experts, what do you advice about asynchronous events: to Block or
> to dispatch selected awt events...
>
> I think that before answer this question we need to clarify why the
> current code hangs.
>

According to me, Martin already exposed his detailled analysis of 2 cases
making AWT to hang with several AppContexts: in summary, like a deadlock,
the EDT threads are waiting for each other to dispatch SequencedEvents !

Please Martin correct me, or maybe give us an updated diagnostic of the
problem ?

This thread is already quite long and both Martin & me invested a lot of
time on debugging, fixing & testing, please give us your understanding,
Sergey.

Finally I am in favor of Martin's patch 2 sent by Oct 16th:
http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02

Cheers,
Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Sergey Bylokhov]

On 23/10/2018 07:08, Laurent Bourgès wrote:

Hi Martin,
The deadline for JDK 11.0.2 is Sunday 28 October !

I suppose this patch will not be reviewed and backported soon... 😭

AWT experts, what do you advice about asynchronous events: to Block or to 
dispatch selected awt events...


I think that before answer this question we need to clarify why the current 
code hangs.



See my mail sent on Thu, Oct 18, 2018 at 4:35 PM.

Cheers,
Laurent

Le lun. 22 oct. 2018 à 18:08, Martin Balao mailto:mba...@redhat.com>> a écrit :

Hi Laurent,

Thanks for confirming this. I'm not surprised by the results you got: it's 
pretty clear that there is something on the macOS windows subsystem that is 
preventing this bug from easily showing there -but your 1st reproducer does not 
depend on that-.

Kind regards,
Martin.-

On Thu, Oct 18, 2018 at 9:46 PM, Laurent Bourgès mailto:bourges.laur...@gmail.com>> wrote:

Martin & Sergey,

Here are my test results on macOS New Sierra:

$ uname -a

Darwin  17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 
PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64


$ source ~/Desktop/test-jdk11.sh

openjdk version "11" 2018-09-25

OpenJDK Runtime Environment 18.9 (build 11+28)

OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)


$ java TestWinEvent

java.lang.IllegalStateException: Total [0] != expected [400] !


$ java TestSeqEventsMultipleContexts

Total [400] - Expected [400]

Test PASSED


So I conclude my former test submitting SequencedEvent directly fails 
in contrary to using the public Window toBack()/toFront() API on MacOS.
I suppose these last methods do not emit SequencedEvent on macOS 
(native code) ?

Finally I am a bit annoyed that the TestSeqEventsMultipleContexts does 
not fail on mac, but fails on other platforms Yes, so it is enough for me.
Sergey, should I test on windows too ?

To conclude, I tried adopting a more conservative approach in my last 
hack, but I needed dispatching InvocationEvents to let swing.Timer continue to 
work.
I do not know if it is better to select which events to accept (while 
list) or to select which events not reject (black list): it depends on the 
number of cases.

Best Regards,
Laurent

Le jeu. 18 oct. 2018 à 16:42, Martin Balao mailto:mba...@redhat.com>> a écrit :

Yes, your results are exactly what I was expecting.

On Thu, Oct 18, 2018 at 4:35 PM, Laurent Bourgès mailto:bourges.laur...@gmail.com>> wrote:

Hi Martin,

Here are my test outputs:

1/ First
$ java TestWinEvent
reject ID = 1200 : 
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@28985415,notifier=null,catchExceptions=false,when=1539872732255]
 on sun.awt.X11.XToolkit@4645926f
reject ID = 1200 : 
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a954cb5,notifier=null,catchExceptions=false,when=1539872733214]
 on sun.awt.X11.XToolkit@4645926f
reject ID = 1200 : 
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@1208f81d,notifier=null,catchExceptions=false,when=1539872733286]
 on sun.awt.X11.XToolkit@4645926f
reject ID = 1100 : 
java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED, no text, 0 
characters committed, no caret, no visible position] on 
javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@75806c8,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
 2,defaultCapable=true]
reject ID = 1200 : 
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a6b3cd6,notifier=null,catchExceptions=false,when=1539872733215]
 on sun.awt.X11.XToolkit@4645926f
java.lang.IllegalStateException: Total [4] != expected [400] !
     at TestWinEvent.main(TestWinEvent.java:53)

*java.lang.IllegalStateException: Total [4] != expected [400] !*

$ java TestSeqEventsMultipleContexts
java TestSeqEventsMultipleContexts
reject ID = 1200 : 
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@6d620f31,notifier=null,catchExceptions=false,when=1539872801695]
 on sun.awt.X11.XToolkit@65746729
reject ID = 1200 : 
java.awt.event.InvocationEvent[INVOCATION_DE

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,
The deadline for JDK 11.0.2 is Sunday 28 October !

I suppose this patch will not be reviewed and backported soon... 😭

AWT experts, what do you advice about asynchronous events: to Block or to
dispatch selected awt events...

See my mail sent on Thu, Oct 18, 2018 at 4:35 PM.

Cheers,
Laurent

Le lun. 22 oct. 2018 à 18:08, Martin Balao  a écrit :

> Hi Laurent,
>
> Thanks for confirming this. I'm not surprised by the results you got: it's
> pretty clear that there is something on the macOS windows subsystem that is
> preventing this bug from easily showing there -but your 1st reproducer does
> not depend on that-.
>
> Kind regards,
> Martin.-
>
> On Thu, Oct 18, 2018 at 9:46 PM, Laurent Bourgès <
> bourges.laur...@gmail.com> wrote:
>
>> Martin & Sergey,
>>
>> Here are my test results on macOS New Sierra:
>>
>> $ uname -a
>>
>> Darwin  17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT
>> 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
>>
>>
>> $ source ~/Desktop/test-jdk11.sh
>>
>> openjdk version "11" 2018-09-25
>>
>> OpenJDK Runtime Environment 18.9 (build 11+28)
>>
>> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>>
>>
>> $ java TestWinEvent
>>
>> java.lang.IllegalStateException: Total [0] != expected [400] !
>>
>>
>> $ java TestSeqEventsMultipleContexts
>>
>> Total [400] - Expected [400]
>>
>> Test PASSED
>>
>> So I conclude my former test submitting SequencedEvent directly fails in
>> contrary to using the public Window toBack()/toFront() API on MacOS.
>> I suppose these last methods do not emit SequencedEvent on macOS (native
>> code) ?
>>
>> Finally I am a bit annoyed that the TestSeqEventsMultipleContexts does
>> not fail on mac, but fails on other platforms Yes, so it is enough for me.
>> Sergey, should I test on windows too ?
>>
>> To conclude, I tried adopting a more conservative approach in my last
>> hack, but I needed dispatching InvocationEvents to let swing.Timer continue
>> to work.
>> I do not know if it is better to select which events to accept (while
>> list) or to select which events not reject (black list): it depends on the
>> number of cases.
>>
>> Best Regards,
>> Laurent
>>
>> Le jeu. 18 oct. 2018 à 16:42, Martin Balao  a écrit :
>>
>>> Yes, your results are exactly what I was expecting.
>>>
>>> On Thu, Oct 18, 2018 at 4:35 PM, Laurent Bourgès <
>>> bourges.laur...@gmail.com> wrote:
>>>
 Hi Martin,

 Here are my test outputs:

 1/ First
 $ java TestWinEvent
 reject ID = 1200 :
 java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@28985415,notifier=null,catchExceptions=false,when=1539872732255]
 on sun.awt.X11.XToolkit@4645926f
 reject ID = 1200 :
 java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a954cb5,notifier=null,catchExceptions=false,when=1539872733214]
 on sun.awt.X11.XToolkit@4645926f
 reject ID = 1200 :
 java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@1208f81d,notifier=null,catchExceptions=false,when=1539872733286]
 on sun.awt.X11.XToolkit@4645926f
 reject ID = 1100 :
 java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED, no text, 0
 characters committed, no caret, no visible position] on
 javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@75806c8,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
 2,defaultCapable=true]
 reject ID = 1200 :
 java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a6b3cd6,notifier=null,catchExceptions=false,when=1539872733215]
 on sun.awt.X11.XToolkit@4645926f
 java.lang.IllegalStateException: Total [4] != expected [400] !
 at TestWinEvent.main(TestWinEvent.java:53)

 *java.lang.IllegalStateException: Total [4] != expected [400] !*

 $ java TestSeqEventsMultipleContexts
 java TestSeqEventsMultipleContexts
 reject ID = 1200 :
 java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@6d620f31,notifier=null,catchExceptions=false,when=1539872801695]
 on sun.awt.X11.XToolkit@65746729
 reject ID = 1200 :
 java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@2bfb82e8,notifier=null,catchExceptions=false,when=1539872801890]
 on sun.awt.X11.XToolkit@65746729
 reject ID = 1200 :
 java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@754b4fe7,notifier=null,catchExceptions=false,when=1539872801894]
 on sun.awt.X1

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Laurent,

Thanks for confirming this. I'm not surprised by the results you got: it's
pretty clear that there is something on the macOS windows subsystem that is
preventing this bug from easily showing there -but your 1st reproducer does
not depend on that-.

Kind regards,
Martin.-

On Thu, Oct 18, 2018 at 9:46 PM, Laurent Bourgès 
wrote:

> Martin & Sergey,
>
> Here are my test results on macOS New Sierra:
>
> $ uname -a
>
> Darwin  17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT
> 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
>
>
> $ source ~/Desktop/test-jdk11.sh
>
> openjdk version "11" 2018-09-25
>
> OpenJDK Runtime Environment 18.9 (build 11+28)
>
> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>
>
> $ java TestWinEvent
>
> java.lang.IllegalStateException: Total [0] != expected [400] !
>
>
> $ java TestSeqEventsMultipleContexts
>
> Total [400] - Expected [400]
>
> Test PASSED
>
> So I conclude my former test submitting SequencedEvent directly fails in
> contrary to using the public Window toBack()/toFront() API on MacOS.
> I suppose these last methods do not emit SequencedEvent on macOS (native
> code) ?
>
> Finally I am a bit annoyed that the TestSeqEventsMultipleContexts does
> not fail on mac, but fails on other platforms Yes, so it is enough for me.
> Sergey, should I test on windows too ?
>
> To conclude, I tried adopting a more conservative approach in my last
> hack, but I needed dispatching InvocationEvents to let swing.Timer continue
> to work.
> I do not know if it is better to select which events to accept (while
> list) or to select which events not reject (black list): it depends on the
> number of cases.
>
> Best Regards,
> Laurent
>
> Le jeu. 18 oct. 2018 à 16:42, Martin Balao  a écrit :
>
>> Yes, your results are exactly what I was expecting.
>>
>> On Thu, Oct 18, 2018 at 4:35 PM, Laurent Bourgès <
>> bourges.laur...@gmail.com> wrote:
>>
>>> Hi Martin,
>>>
>>> Here are my test outputs:
>>>
>>> 1/ First
>>> $ java TestWinEvent
>>> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
>>> DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@28985415,
>>> notifier=null,catchExceptions=false,when=1539872732255] on
>>> sun.awt.X11.XToolkit@4645926f
>>> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
>>> DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a954cb5,
>>> notifier=null,catchExceptions=false,when=1539872733214] on
>>> sun.awt.X11.XToolkit@4645926f
>>> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
>>> DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@1208f81d,
>>> notifier=null,catchExceptions=false,when=1539872733286] on
>>> sun.awt.X11.XToolkit@4645926f
>>> reject ID = 1100 : 
>>> java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED,
>>> no text, 0 characters committed, no caret, no visible position] on
>>> javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,
>>> alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$
>>> CompoundBorderUIResource@75806c8,flags=296,maximumSize=
>>> ,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,
>>> disabledSelectedIcon=,margin=javax.swing.plaf.
>>> InsetsUIResource[top=2,left=14,bottom=2,right=14],
>>> paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,
>>> rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
>>> 2,defaultCapable=true]
>>> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
>>> DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a6b3cd6,
>>> notifier=null,catchExceptions=false,when=1539872733215] on
>>> sun.awt.X11.XToolkit@4645926f
>>> java.lang.IllegalStateException: Total [4] != expected [400] !
>>> at TestWinEvent.main(TestWinEvent.java:53)
>>>
>>> *java.lang.IllegalStateException: Total [4] != expected [400] !*
>>>
>>> $ java TestSeqEventsMultipleContexts
>>> java TestSeqEventsMultipleContexts
>>> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
>>> DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@6d620f31,
>>> notifier=null,catchExceptions=false,when=1539872801695] on
>>> sun.awt.X11.XToolkit@65746729
>>> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
>>> DEFAULT,runnable=javax.swing.Timer$DoPostEvent@2bfb82e8,
>>> notifier=null,catchExceptions=false,when=1539872801890] on
>>> sun.awt.X11.XToolkit@65746729
>>> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
>>> DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@754b4fe7,
>>> notifier=null,catchExceptions=false,when=1539872801894] on
>>> sun.awt.X11.XToolkit@65746729
>>> reject ID = 1100 : 
>>> java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED,
>>> no text, 0 characters committed, no caret, no visible position] on
>>> javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,
>>> alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$
>>> CompoundBorderUIResource@51861d7a,flags=296,maximumSize=,minimumSize=,
>>> preferredSize=,defaultIcon=,disabledIcon=,disable

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Martin & Sergey,

Here are my test results on macOS New Sierra:

$ uname -a

Darwin  17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT
2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64


$ source ~/Desktop/test-jdk11.sh

openjdk version "11" 2018-09-25

OpenJDK Runtime Environment 18.9 (build 11+28)

OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)


$ java TestWinEvent

java.lang.IllegalStateException: Total [0] != expected [400] !


$ java TestSeqEventsMultipleContexts

Total [400] - Expected [400]

Test PASSED

So I conclude my former test submitting SequencedEvent directly fails in
contrary to using the public Window toBack()/toFront() API on MacOS.
I suppose these last methods do not emit SequencedEvent on macOS (native
code) ?

Finally I am a bit annoyed that the TestSeqEventsMultipleContexts does not
fail on mac, but fails on other platforms Yes, so it is enough for me.
Sergey, should I test on windows too ?

To conclude, I tried adopting a more conservative approach in my last hack,
but I needed dispatching InvocationEvents to let swing.Timer continue to
work.
I do not know if it is better to select which events to accept (while list)
or to select which events not reject (black list): it depends on the number
of cases.

Best Regards,
Laurent

Le jeu. 18 oct. 2018 à 16:42, Martin Balao  a écrit :

> Yes, your results are exactly what I was expecting.
>
> On Thu, Oct 18, 2018 at 4:35 PM, Laurent Bourgès <
> bourges.laur...@gmail.com> wrote:
>
>> Hi Martin,
>>
>> Here are my test outputs:
>>
>> 1/ First
>> $ java TestWinEvent
>> reject ID = 1200 :
>> java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@28985415,notifier=null,catchExceptions=false,when=1539872732255]
>> on sun.awt.X11.XToolkit@4645926f
>> reject ID = 1200 :
>> java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a954cb5,notifier=null,catchExceptions=false,when=1539872733214]
>> on sun.awt.X11.XToolkit@4645926f
>> reject ID = 1200 :
>> java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@1208f81d,notifier=null,catchExceptions=false,when=1539872733286]
>> on sun.awt.X11.XToolkit@4645926f
>> reject ID = 1100 :
>> java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED, no text, 0
>> characters committed, no caret, no visible position] on
>> javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@75806c8,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
>> 2,defaultCapable=true]
>> reject ID = 1200 :
>> java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a6b3cd6,notifier=null,catchExceptions=false,when=1539872733215]
>> on sun.awt.X11.XToolkit@4645926f
>> java.lang.IllegalStateException: Total [4] != expected [400] !
>> at TestWinEvent.main(TestWinEvent.java:53)
>>
>> *java.lang.IllegalStateException: Total [4] != expected [400] !*
>>
>> $ java TestSeqEventsMultipleContexts
>> java TestSeqEventsMultipleContexts
>> reject ID = 1200 :
>> java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@6d620f31,notifier=null,catchExceptions=false,when=1539872801695]
>> on sun.awt.X11.XToolkit@65746729
>> reject ID = 1200 :
>> java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@2bfb82e8,notifier=null,catchExceptions=false,when=1539872801890]
>> on sun.awt.X11.XToolkit@65746729
>> reject ID = 1200 :
>> java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@754b4fe7,notifier=null,catchExceptions=false,when=1539872801894]
>> on sun.awt.X11.XToolkit@65746729
>> reject ID = 1100 :
>> java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED, no text, 0
>> characters committed, no caret, no visible position] on
>> javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@51861d7a,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
>> 4,defaultCapable=true]
>> reject ID = 1200 :
>> java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@e20778b,notifier=null,catchExceptions=false,when=1539872801893]
>> on sun.awt.X11.XToolkit@65746729
>>
>> *Total [8] - Expected [400]Test FAILED*
>>
>> So the TestSeqEventsMultipleContexts is failing now:
>> Inv

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Yes, your results are exactly what I was expecting.

On Thu, Oct 18, 2018 at 4:35 PM, Laurent Bourgès 
wrote:

> Hi Martin,
>
> Here are my test outputs:
>
> 1/ First
> $ java TestWinEvent
> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
> DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@28985415,
> notifier=null,catchExceptions=false,when=1539872732255] on
> sun.awt.X11.XToolkit@4645926f
> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
> DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a954cb5,
> notifier=null,catchExceptions=false,when=1539872733214] on
> sun.awt.X11.XToolkit@4645926f
> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
> DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@1208f81d,
> notifier=null,catchExceptions=false,when=1539872733286] on
> sun.awt.X11.XToolkit@4645926f
> reject ID = 1100 : java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED,
> no text, 0 characters committed, no caret, no visible position] on
> javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,
> alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$
> CompoundBorderUIResource@75806c8,flags=296,maximumSize=
> ,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,
> disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=
> 14,bottom=2,right=14],paintBorder=true,paintFocus=true,pressedIcon=,
> rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
> 2,defaultCapable=true]
> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
> DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a6b3cd6,
> notifier=null,catchExceptions=false,when=1539872733215] on
> sun.awt.X11.XToolkit@4645926f
> java.lang.IllegalStateException: Total [4] != expected [400] !
> at TestWinEvent.main(TestWinEvent.java:53)
>
> *java.lang.IllegalStateException: Total [4] != expected [400] !*
>
> $ java TestSeqEventsMultipleContexts
> java TestSeqEventsMultipleContexts
> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
> DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@6d620f31,
> notifier=null,catchExceptions=false,when=1539872801695] on
> sun.awt.X11.XToolkit@65746729
> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
> DEFAULT,runnable=javax.swing.Timer$DoPostEvent@2bfb82e8,
> notifier=null,catchExceptions=false,when=1539872801890] on
> sun.awt.X11.XToolkit@65746729
> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
> DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@754b4fe7,
> notifier=null,catchExceptions=false,when=1539872801894] on
> sun.awt.X11.XToolkit@65746729
> reject ID = 1100 : java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED,
> no text, 0 characters committed, no caret, no visible position] on
> javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,
> alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$
> CompoundBorderUIResource@51861d7a,flags=296,maximumSize=,minimumSize=,
> preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=
> javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],
> paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,
> rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
> 4,defaultCapable=true]
> reject ID = 1200 : java.awt.event.InvocationEvent[INVOCATION_
> DEFAULT,runnable=javax.swing.Timer$DoPostEvent@e20778b,
> notifier=null,catchExceptions=false,when=1539872801893] on
> sun.awt.X11.XToolkit@65746729
>
> *Total [8] - Expected [400]Test FAILED*
>
> So the TestSeqEventsMultipleContexts is failing now:
> InvocationEvent must be dispatched as the test uses a Timer() to post 1
> event at a time (and avoid polluting the event queue in contrary to the
> initial TestWinEvent).
>
> 2/ Dispatch InvocationEvents:
>
>
> $ java TestWinEvent
> reject ID = 1100 : java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED,
> no text, 0 characters committed, no caret, no visible position] on
> javax.swing.JButton[,0,51,300x25,alignmentX=0.0,
> alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$
> CompoundBorderUIResource@25550fd7,flags=296,maximumSize=,minimumSize=,
> preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=
> javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],
> paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,
> rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
> 45,defaultCapable=true]
> reject ID = 103 : java.awt.event.ComponentEvent[COMPONENT_HIDDEN] on
> frame0
>
> $ java TestSeqEventsMultipleContexts
> reject ID = 1100 : java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED,
> no text, 0 characters committed, no caret, no visible position] on
> javax.swing.JButton[,0,51,300x25,alignmentX=0.0,
> alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$
> CompoundBorderUIResource@70122df1,flags=296,maximumSize=,minimumSize=,
> preferredSize=,defaultIcon=,disabledIcon=,disabledSele

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,

Here are my test outputs:

1/ First
$ java TestWinEvent
reject ID = 1200 :
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@28985415,notifier=null,catchExceptions=false,when=1539872732255]
on sun.awt.X11.XToolkit@4645926f
reject ID = 1200 :
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a954cb5,notifier=null,catchExceptions=false,when=1539872733214]
on sun.awt.X11.XToolkit@4645926f
reject ID = 1200 :
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@1208f81d,notifier=null,catchExceptions=false,when=1539872733286]
on sun.awt.X11.XToolkit@4645926f
reject ID = 1100 :
java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED, no text, 0
characters committed, no caret, no visible position] on
javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@75806c8,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
2,defaultCapable=true]
reject ID = 1200 :
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@1a6b3cd6,notifier=null,catchExceptions=false,when=1539872733215]
on sun.awt.X11.XToolkit@4645926f
java.lang.IllegalStateException: Total [4] != expected [400] !
at TestWinEvent.main(TestWinEvent.java:53)

*java.lang.IllegalStateException: Total [4] != expected [400] !*

$ java TestSeqEventsMultipleContexts
java TestSeqEventsMultipleContexts
reject ID = 1200 :
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@6d620f31,notifier=null,catchExceptions=false,when=1539872801695]
on sun.awt.X11.XToolkit@65746729
reject ID = 1200 :
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@2bfb82e8,notifier=null,catchExceptions=false,when=1539872801890]
on sun.awt.X11.XToolkit@65746729
reject ID = 1200 :
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.RepaintManager$ProcessingRunnable@754b4fe7,notifier=null,catchExceptions=false,when=1539872801894]
on sun.awt.X11.XToolkit@65746729
reject ID = 1100 :
java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED, no text, 0
characters committed, no caret, no visible position] on
javax.swing.JButton[,0,51,300x25,invalid,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@51861d7a,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
4,defaultCapable=true]
reject ID = 1200 :
java.awt.event.InvocationEvent[INVOCATION_DEFAULT,runnable=javax.swing.Timer$DoPostEvent@e20778b,notifier=null,catchExceptions=false,when=1539872801893]
on sun.awt.X11.XToolkit@65746729

*Total [8] - Expected [400]Test FAILED*

So the TestSeqEventsMultipleContexts is failing now:
InvocationEvent must be dispatched as the test uses a Timer() to post 1
event at a time (and avoid polluting the event queue in contrary to the
initial TestWinEvent).

2/ Dispatch InvocationEvents:


$ java TestWinEvent
reject ID = 1100 :
java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED, no text, 0
characters committed, no caret, no visible position] on
javax.swing.JButton[,0,51,300x25,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@25550fd7,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
45,defaultCapable=true]
reject ID = 103 : java.awt.event.ComponentEvent[COMPONENT_HIDDEN] on frame0

$ java TestSeqEventsMultipleContexts
reject ID = 1100 :
java.awt.event.InputMethodEvent[INPUT_METHOD_TEXT_CHANGED, no text, 0
characters committed, no caret, no visible position] on
javax.swing.JButton[,0,51,300x25,alignmentX=0.0,alignmentY=0.5,border=javax.swing.plaf.BorderUIResource$CompoundBorderUIResource@70122df1,flags=296,maximumSize=,minimumSize=,preferredSize=,defaultIcon=,disabledIcon=,disabledSelectedIcon=,margin=javax.swing.plaf.InsetsUIResource[top=2,left=14,bottom=2,right=14],paintBorder=true,paintFocus=true,pressedIcon=,rolloverEnabled=true,rolloverIcon=,rolloverSelectedIcon=,selectedIcon=,text=TEST
17,defaultCapable=true]

*Total [400] - Expected [400]Test PASSED*

Here is my last hack:
private static final class 

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

On Thu, Oct 18, 2018 at 3:58 PM, Laurent Bourgès 
wrote:

> Hi Martin,
>
> PS: could you tell me what lines to change to discard non sequenced events
>>> in your patch ? I will then try it
>>>
>>
>> Instead of "if (ev.getID() == ID) { ... } return FilterAction.ACCEPT;",
>> do:
>>
>> "if (ev.getID() == ID) { ... }  else if (ev.getID() == SentEvent.ID) {
>> return FilterAction.ACCEPT; } return FilterAction.REJECT;"
>>
>> SequencedEvent and SentEvent events accepted, others rejected.
>>
>
>
It would be really nice if you could:

 1) find if hardware generated events are wrapped or not in SequencedEvent
events; and,

 2) find which are the non-SequencedEvent events, and what kind of
dependency there could be with SequencedEvents events.

Thanks!

Martin.-

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,

PS: could you tell me what lines to change to discard non sequenced events
>> in your patch ? I will then try it
>>
>
> Instead of "if (ev.getID() == ID) { ... } return FilterAction.ACCEPT;", do:
>
> "if (ev.getID() == ID) { ... }  else if (ev.getID() == SentEvent.ID) {
> return FilterAction.ACCEPT; } return FilterAction.REJECT;"
>
> SequencedEvent and SentEvent events accepted, others rejected.
>

I modified your patch with:
private static final class SequencedEventsFilter implements EventFilter
{
private final SequencedEvent currentSequencedEvent;
private SequencedEventsFilter(SequencedEvent currentSequencedEvent)
{
this.currentSequencedEvent = currentSequencedEvent;
}
@Override
public FilterAction acceptEvent(AWTEvent ev) {
if (ev.getID() == ID) {
// Move forward dispatching only if the event is previous
// in SequencedEvent.list. Otherwise, hold it for reposting
later.
synchronized (SequencedEvent.class) {
Iterator it = list.iterator();
while (it.hasNext()) {
SequencedEvent iev = it.next();
if (iev.equals(currentSequencedEvent)) {
break;
} else if (iev.equals(ev)) {
return FilterAction.ACCEPT;
}
}
}
currentSequencedEvent.pendingEvents.add(ev);
return FilterAction.REJECT;



*   } else if (ev.getID() == SentEvent.ID) { return
FilterAction.ACCEPT;}return FilterAction.REJECT;*
}
}

The new Test passed (400: OK) but I agree the GUI is not correctly
repainted (button labels are more or less never refreshed).

I will try diagnosing which events are discarded...

Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

On Thu, Oct 18, 2018 at 12:14 PM, Laurent Bourgès  wrote:
>
>
> PS: could you tell me what lines to change to discard non sequenced events
> in your patch ? I will then try it
>
>
Instead of "if (ev.getID() == ID) { ... } return FilterAction.ACCEPT;", do:

"if (ev.getID() == ID) { ... }  else if (ev.getID() == SentEvent.ID) {
return FilterAction.ACCEPT; } return FilterAction.REJECT;"

SequencedEvent and SentEvent events accepted, others rejected.

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Martin,


>> Have you tried Laurent's test case on Mac? (the version previous to my
>>> refactorings, so we eliminate the OS layer). This bug should manifest there
>>> too. Unfortunately, I don't have such environment to test and debug.
>>>
>>
>> Yes, it is not reproduced on macos, at-least not so easy like on win/lin.
>>
>
> I should have said, the first version of Laurent's test [1]. Perhaps some
> tweaks are still needed; we need a test that artificially injects the
> events and does not depend on the OS UI subsystem. But the problem should
> be there too.
>

I will run my initial reproducer test on macOS New Sierra with OpenJDK11
now and tell you its results.

PS: could you tell me what lines to change to discard non sequenced events
in your patch ? I will then try it

Cheers,
Laurent

>

Re: OpenJdk11-28-EA JDialog hanging

[Krishna Addepalli]

Hi Martin,

As far as my experience goes(which is less), the usage of SequencedEvents is 
relatively rare, and rarer even to generate a high volume of SequencedEvents.
So, I would be inclined to pursue the path of blocking the dispatch till the 
SequencedEvents are processed.
Probably Sergey/Phil are more qualified to comment on this, but this is my 2 
cents!

Thanks,
Krishna

> On 18-Oct-2018, at 2:15 PM, Martin Balao  wrote:
> 
> Hi Laurent,
> 
> On Wed, Oct 17, 2018 at 8:13 PM, Laurent Bourgès  > wrote:
> If the behavior changed in your patch, it sounds more conservative to discard 
> events (as before) if the present bug is still fixed.
> It could be revisited later in another appropriate bug.
> Is it a trivial change in your event filter ? I am looking forward trying 
> this alternative sllution.
> 
> I believe that this decision -whether we dispatch, block o completely change 
> the approach- has to be taken as part of this bug. We would need to further 
> investigate, particularly on the SequencedEvent clients side.
> 
> Discarding non-SequencedEvent events or holding them for the future is a 
> trivial change. In fact, I tried it some days ago before proposing the latest 
> version of the patch. What I noticed in your test at [1] was: events were 
> injected at a high rate, the SequencedEvent.list list steadily grew, the EDT 
> was very busy dispatching them -"blocked" like- and there was no room for 
> dispatching other events keeping the GUI unresponsive -they were rejected by 
> the waiting filter-. If I remember correctly, repainting after changing the 
> counter was affected by this.
> 
> Regards,
> Martin.-
> 
> --
> [1] - http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html 
> 

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

On Thu, Oct 18, 2018 at 11:05 AM, Laurent Bourgès  wrote:
>
>
> There is no shame that EDT or event processing consuming lots of cpu
> cycles, in such intensive tests.
>
>
That's not a problem, the problem is starvation of
non-SequencedEvent events if the EDT is blocked-like rejecting them all.
Even though all of this is artificially caused, it's a good opportunity to
get it right and it's actually very nice that your 1st test exposed this
scenario.

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Sergey,

On Thu, Oct 18, 2018 at 3:35 AM, Sergey Bylokhov  wrote:

> On 17/10/2018 07:12, Martin Balao wrote:
>
>> Have you tried Laurent's test case on Mac? (the version previous to my
>> refactorings, so we eliminate the OS layer). This bug should manifest there
>> too. Unfortunately, I don't have such environment to test and debug.
>>
>
> Yes, it is not reproduced on macos, at-least not so easy like on win/lin.
>

I should have said, the first version of Laurent's test [1]. Perhaps some
tweaks are still needed; we need a test that artificially injects the
events and does not depend on the OS UI subsystem. But the problem should
be there too.


>
> __2.__I’m not sure if I agree to your proposal of dispatching
>> non-SequencedEvents, from the queue. The events arriving after a particular
>> SequencedEvent could be dependent on this event – for example, the current
>> SequencedEvent could be a focus change event, and the subsequent events
>> could be Key events. So, as per your solution, if we dispatch them, there
>> is a possibility that the intended component may not receive those events.
>>
>
> An explanation of SequencedEvent above is correct, we need to block the
> thread until another SequencedEvent will be dispatched or for some reason
> will be dropped. This is a functional which allow synchronize execution
> between different EDT(per Appcontex). This is a rare case, which mostly
> related to the "focus" functionality, because the java can have only one
> focused element at a time, and we need to manage it between different
> applications inside jvm. One application is webstart itself and another is
> the user's application.


I'll give an example to further illustrate. Let's suppose that we inject a
sequence of 3 windows focus events on different app contexts and 1
keystroke in-between. We will wrap each windows focus event on a
SequencedEvent event -so there is a specific order that has to be honored-
and the keystroke event will not be wrapped. Previous to the proposed
patch, the keystroke event would have been discarded while the EDT is
blocked on the filter -waiting for other SequencedEvent events to be
dispatched before-. With the proposed patch, the keystroke is considered an
asynchronous event (not part of the sequence, not wrapped in a
SequencedEvent) and is dispatched when it comes. My understanding is that
if we want the keystroke to be part of the sequence (synchronized), it has
to be wrapped with a SequencedEvent.

Having said that, I'll further investigate what are the assumptions clients
are having, which events are wrapped on SequencedEvent events and which are
not. At this point, I'm not completely sure if hardware generated events
like keystrokes are wrapped or not.

Going back to Krishna's comment, my understanding is that the Key event
(assuming it's a non-SequencedEvent event) would have been lost previous to
this change if the EDT is blocked waiting for a SequencedEvent event.


>
> My understanding is that if you want hard-dependency enforcements, you
>> have to wrap events under SequencedEvent events. All other asynchronous
>> events have absolutely no guarantees. Blocking the EDT should not be done
>> and that's the reason why we dispatch non-SequencedEvent events in the
>> meanwhile. Please note that the only events that are put on hold and
>> re-posted lated are SequencedEvent events that, if dispatched, would
>> violate the sequence rule.
>>
>
> It is still unclear what is going wrong, based on the stack trace it is
> clear that a few SequencedEvent waits each other, but why the last(or
> first) SequencedEvent, which should flush this queue, was not dispatched?
> Is it possible that this event was dropped for some reason, like its source
> was disposed, the appcontext itself was disposed, any other reasons?
>
>
What is going wrong where? Which stack trace do you mean?

Kind regards,
Martin.-

--
[1] -
http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,

If the behavior changed in your patch, it sounds more conservative to
>> discard events (as before) if the present bug is still fixed.
>> It could be revisited later in another appropriate bug.
>> Is it a trivial change in your event filter ? I am looking forward trying
>> this alternative sllution.
>>
>
> I believe that this decision -whether we dispatch, block o completely
> change the approach- has to be taken as part of this bug. We would need to
> further investigate, particularly on the SequencedEvent clients side.
>

I agree. I think Sergey & Krishna prefer discarding non - SequencedEvent as
before (for compatibility reasons).

Discarding non-SequencedEvent events or holding them for the future is a
> trivial change. In fact, I tried it some days ago before proposing the
> latest version of the patch. What I noticed in your test at [1] was: events
> were injected at a high rate, the SequencedEvent.list list steadily grew,
> the EDT was very busy dispatching them -"blocked" like- and there was no
> room for dispatching other events keeping the GUI unresponsive -they were
> rejected by the waiting filter-. If I remember correctly, repainting after
> changing the counter was affected by this.
>

My former test was more a crash test with intensive event submission.
The new test is more 'cool', as it only uses public Window events
(toBack(), toFront() and I am interested to test it with another patch
variant discarding events.

There is no shame that EDT or event processing consuming lots of cpu
cycles, in such intensive tests.
If the bug is fixed, and GUI is still responsive, that's fine to me.

Kind regards,
Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Laurent,

On Wed, Oct 17, 2018 at 8:13 PM, Laurent Bourgès 
wrote:
>
> If the behavior changed in your patch, it sounds more conservative to
> discard events (as before) if the present bug is still fixed.
> It could be revisited later in another appropriate bug.
> Is it a trivial change in your event filter ? I am looking forward trying
> this alternative sllution.
>

I believe that this decision -whether we dispatch, block o completely
change the approach- has to be taken as part of this bug. We would need to
further investigate, particularly on the SequencedEvent clients side.

Discarding non-SequencedEvent events or holding them for the future is a
trivial change. In fact, I tried it some days ago before proposing the
latest version of the patch. What I noticed in your test at [1] was: events
were injected at a high rate, the SequencedEvent.list list steadily grew,
the EDT was very busy dispatching them -"blocked" like- and there was no
room for dispatching other events keeping the GUI unresponsive -they were
rejected by the waiting filter-. If I remember correctly, repainting after
changing the counter was affected by this.

Regards,
Martin.-

--
[1] -
http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014429.html

Re: OpenJdk11-28-EA JDialog hanging

[Sergey Bylokhov]

On 17/10/2018 07:12, Martin Balao wrote:

Have you tried Laurent's test case on Mac? (the version previous to my 
refactorings, so we eliminate the OS layer). This bug should manifest there 
too. Unfortunately, I don't have such environment to test and debug.


Yes, it is not reproduced on macos, at-least not so easy like on win/lin.


__2.__I’m not sure if I agree to your proposal of dispatching 
non-SequencedEvents, from the queue. The events arriving after a particular 
SequencedEvent could be dependent on this event – for example, the current 
SequencedEvent could be a focus change event, and the subsequent events could 
be Key events. So, as per your solution, if we dispatch them, there is a 
possibility that the intended component may not receive those events.


An explanation of SequencedEvent above is correct, we need to block the thread until 
another SequencedEvent will be dispatched or for some reason will be dropped. This is a 
functional which allow synchronize execution between different EDT(per Appcontex). This 
is a rare case, which mostly related to the "focus" functionality, because the 
java can have only one focused element at a time, and we need to manage it between 
different applications inside jvm. One application is webstart itself and another is the 
user's application.


My understanding is that if you want hard-dependency enforcements, you have to 
wrap events under SequencedEvent events. All other asynchronous events have 
absolutely no guarantees. Blocking the EDT should not be done and that's the 
reason why we dispatch non-SequencedEvent events in the meanwhile. Please note 
that the only events that are put on hold and re-posted lated are 
SequencedEvent events that, if dispatched, would violate the sequence rule.


It is still unclear what is going wrong, based on the stack trace it is clear 
that a few SequencedEvent waits each other, but why the last(or first) 
SequencedEvent, which should flush this queue, was not dispatched? Is it 
possible that this event was dropped for some reason, like its source was 
disposed, the appcontext itself was disposed, any other reasons?

--
Best regards, Sergey.

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Martin,

Le mer. 17 oct. 2018 à 18:33, Martin Balao  a écrit :

> I've re-read the description of SequencedEvent and could not find any
> atomicity requirements. I mean, we can do it by either discarding events
> (as before) or by holding them for the future (as we do with out-of-order
> SequencedEvent events), but this would block the EDT and I'm not convinced
> to do so.
>

If the behavior changed in your patch, it sounds more conservative to
discard events (as before) if the present bug is still fixed.
It could be revisited later in another appropriate bug.
Is it a trivial change in your event filter ? I am looking forward trying
this alternative sllution.


> BTW: this may explain the "null windows source" error we noticed with
> Laurent under the test stress conditions.
>

I am understanding now why this side effect happened few times in my tests.

Thanks,
Laurent

>
> On Wed, Oct 17, 2018 at 6:05 PM, Martin Balao  wrote:
>
>> On Wed, Oct 17, 2018 at 5:34 PM, Laurent Bourgès <
>> bourges.laur...@gmail.com> wrote:
>>
>>> Martin,
>>>
 2.   I’m not sure if I agree to your proposal of dispatching
> non-SequencedEvents, from the queue. The events arriving after a 
> particular
> SequencedEvent could be dependent on this event – for example, the current
> SequencedEvent could be a focus change event, and the subsequent events
> could be Key events. So, as per your solution, if we dispatch them, there
> is a possibility that the intended component may not receive those events.
>
 My understanding is that if you want hard-dependency enforcements, you
 have to wrap events under SequencedEvent events. All other asynchronous
 events have absolutely no guarantees. Blocking the EDT should not be done
 and that's the reason why we dispatch non-SequencedEvent events in the
 meanwhile. Please note that the only events that are put on hold and
 re-posted lated are SequencedEvent events that, if dispatched, would
 violate the sequence rule.

>>>
>>> I read again the patch code, and did not noticed what is causing other
>>> events go be dispatched instead of blocking.
>>>
>>> Could you explain your logic ?
>>> I jnderstand from  Krishna comment that SequencedEvent induce a
>>> 'barrier' for related events...
>>>
>>
>> The EDT thread must not be blocked for longer periods -that is:
>> discarding or postponing the dispatch of incoming events-, because the
>> whole application gets unresponsive if we do so. Previous to this patch,
>> the filter in-place was discarding all the events except from SentEvent or
>> SequencedEvent events (depending on the revision) while waiting for
>> SequencedEvent events to be processed in the right order.
>>
>> What we do now is dispatching all asynchronous events
>> (non-SequencedEvent) while waiting for SequencedEvent events to be
>> processed in the right order. The rationale behind this decision is that
>> there are no guarantees for asynchronous events in regard to depending on
>> SequencedEvent events. We are just replacing a discard behavior with a
>> dispatch anyways.
>>
>> Of course we comply with SequencedEvent order guarantees. If you need
>> such order guarantees on asynchronous events, you have to wrap any event in
>> SequencedEvent events.
>>
>> In my opinion, if an event depends on another and they are not both
>> wrapped in a SequencedEvent event, that's what is wrong.
>>
>
>

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

I've re-read the description of SequencedEvent and could not find any
atomicity requirements. I mean, we can do it by either discarding events
(as before) or by holding them for the future (as we do with out-of-order
SequencedEvent events), but this would block the EDT and I'm not convinced
to do so.

BTW: this may explain the "null windows source" error we noticed with
Laurent under the test stress conditions.

On Wed, Oct 17, 2018 at 6:05 PM, Martin Balao  wrote:

> On Wed, Oct 17, 2018 at 5:34 PM, Laurent Bourgès <
> bourges.laur...@gmail.com> wrote:
>
>> Martin,
>>
>>> 2.   I’m not sure if I agree to your proposal of dispatching
 non-SequencedEvents, from the queue. The events arriving after a particular
 SequencedEvent could be dependent on this event – for example, the current
 SequencedEvent could be a focus change event, and the subsequent events
 could be Key events. So, as per your solution, if we dispatch them, there
 is a possibility that the intended component may not receive those events.

>>> My understanding is that if you want hard-dependency enforcements, you
>>> have to wrap events under SequencedEvent events. All other asynchronous
>>> events have absolutely no guarantees. Blocking the EDT should not be done
>>> and that's the reason why we dispatch non-SequencedEvent events in the
>>> meanwhile. Please note that the only events that are put on hold and
>>> re-posted lated are SequencedEvent events that, if dispatched, would
>>> violate the sequence rule.
>>>
>>
>> I read again the patch code, and did not noticed what is causing other
>> events go be dispatched instead of blocking.
>>
>> Could you explain your logic ?
>> I jnderstand from  Krishna comment that SequencedEvent induce a 'barrier'
>> for related events...
>>
>
> The EDT thread must not be blocked for longer periods -that is: discarding
> or postponing the dispatch of incoming events-, because the whole
> application gets unresponsive if we do so. Previous to this patch, the
> filter in-place was discarding all the events except from SentEvent or
> SequencedEvent events (depending on the revision) while waiting for
> SequencedEvent events to be processed in the right order.
>
> What we do now is dispatching all asynchronous events (non-SequencedEvent)
> while waiting for SequencedEvent events to be processed in the right order.
> The rationale behind this decision is that there are no guarantees for
> asynchronous events in regard to depending on SequencedEvent events. We are
> just replacing a discard behavior with a dispatch anyways.
>
> Of course we comply with SequencedEvent order guarantees. If you need such
> order guarantees on asynchronous events, you have to wrap any event in
> SequencedEvent events.
>
> In my opinion, if an event depends on another and they are not both
> wrapped in a SequencedEvent event, that's what is wrong.
>

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

On Wed, Oct 17, 2018 at 5:34 PM, Laurent Bourgès 
wrote:

> Martin,
>
>> 2.   I’m not sure if I agree to your proposal of dispatching
>>> non-SequencedEvents, from the queue. The events arriving after a particular
>>> SequencedEvent could be dependent on this event – for example, the current
>>> SequencedEvent could be a focus change event, and the subsequent events
>>> could be Key events. So, as per your solution, if we dispatch them, there
>>> is a possibility that the intended component may not receive those events.
>>>
>> My understanding is that if you want hard-dependency enforcements, you
>> have to wrap events under SequencedEvent events. All other asynchronous
>> events have absolutely no guarantees. Blocking the EDT should not be done
>> and that's the reason why we dispatch non-SequencedEvent events in the
>> meanwhile. Please note that the only events that are put on hold and
>> re-posted lated are SequencedEvent events that, if dispatched, would
>> violate the sequence rule.
>>
>
> I read again the patch code, and did not noticed what is causing other
> events go be dispatched instead of blocking.
>
> Could you explain your logic ?
> I jnderstand from  Krishna comment that SequencedEvent induce a 'barrier'
> for related events...
>

The EDT thread must not be blocked for longer periods -that is: discarding
or postponing the dispatch of incoming events-, because the whole
application gets unresponsive if we do so. Previous to this patch, the
filter in-place was discarding all the events except from SentEvent or
SequencedEvent events (depending on the revision) while waiting for
SequencedEvent events to be processed in the right order.

What we do now is dispatching all asynchronous events (non-SequencedEvent)
while waiting for SequencedEvent events to be processed in the right order.
The rationale behind this decision is that there are no guarantees for
asynchronous events in regard to depending on SequencedEvent events. We are
just replacing a discard behavior with a dispatch anyways.

Of course we comply with SequencedEvent order guarantees. If you need such
order guarantees on asynchronous events, you have to wrap any event in
SequencedEvent events.

In my opinion, if an event depends on another and they are not both wrapped
in a SequencedEvent event, that's what is wrong.

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Martin,

> 2.   I’m not sure if I agree to your proposal of dispatching
>> non-SequencedEvents, from the queue. The events arriving after a particular
>> SequencedEvent could be dependent on this event – for example, the current
>> SequencedEvent could be a focus change event, and the subsequent events
>> could be Key events. So, as per your solution, if we dispatch them, there
>> is a possibility that the intended component may not receive those events.
>>
> My understanding is that if you want hard-dependency enforcements, you
> have to wrap events under SequencedEvent events. All other asynchronous
> events have absolutely no guarantees. Blocking the EDT should not be done
> and that's the reason why we dispatch non-SequencedEvent events in the
> meanwhile. Please note that the only events that are put on hold and
> re-posted lated are SequencedEvent events that, if dispatched, would
> violate the sequence rule.
>

I read again the patch code, and did not noticed what is causing other
events go be dispatched instead of blocking.

Could you explain your logic ?
I jnderstand from  Krishna comment that SequencedEvent induce a 'barrier'
for related events...

Laurent

>

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Krishna,

On Wed, Oct 17, 2018 at 3:51 PM, Krishna Addepalli <
krishna.addepa...@oracle.com> wrote:
>
> 1.   This problem (including the one described in JDK-8152974) is not
> reproducible at all in Mac. I would like to understand why this happens
> only on Windows/Linux because the proposed fix is in generic code.
>
Have you tried Laurent's test case on Mac? (the version previous to my
refactorings, so we eliminate the OS layer). This bug should manifest there
too. Unfortunately, I don't have such environment to test and debug.

> 2.   I’m not sure if I agree to your proposal of dispatching
> non-SequencedEvents, from the queue. The events arriving after a particular
> SequencedEvent could be dependent on this event – for example, the current
> SequencedEvent could be a focus change event, and the subsequent events
> could be Key events. So, as per your solution, if we dispatch them, there
> is a possibility that the intended component may not receive those events.
>
My understanding is that if you want hard-dependency enforcements, you have
to wrap events under SequencedEvent events. All other asynchronous events
have absolutely no guarantees. Blocking the EDT should not be done and
that's the reason why we dispatch non-SequencedEvent events in the
meanwhile. Please note that the only events that are put on hold and
re-posted lated are SequencedEvent events that, if dispatched, would
violate the sequence rule.

Kind regards,
Martin.-

Re: OpenJdk11-28-EA JDialog hanging

[Krishna Addepalli]

Hi Martin,

 

Excellent assessment of the problem and great explanation of it. Appreciate 
your efforts in debugging and proposing a solution to this problem.

 

I have couple questions:

1.   This problem (including the one described in JDK-8152974) is not 
reproducible at all in Mac. I would like to understand why this happens only on 
Windows/Linux because the proposed fix is in generic code.

2.   I’m not sure if I agree to your proposal of dispatching 
non-SequencedEvents, from the queue. The events arriving after a particular 
SequencedEvent could be dependent on this event – for example, the current 
SequencedEvent could be a focus change event, and the subsequent events could 
be Key events. So, as per your solution, if we dispatch them, there is a 
possibility that the intended component may not receive those events.

 

Thanks,
Krishna

 

From: Martin Balao  
Sent: Tuesday, October 16, 2018 5:18 PM
To: Laurent Bourgès 
Cc: awt-dev@openjdk.java.net
Subject: Re:  OpenJdk11-28-EA JDialog hanging

 

Hi Laurent,

 

Thanks for your test! Great job :-)

 

I applied some minor changes for integration:

 

 * Renamed to TestSeqEventsMultipleContexts

  * A bit longer but should describe what this is about

  * Placed in jdk/java/awt/event/SequencedEvent

 

 * Encapsulated the window in TestWindow class

 

 * Instead of waiting 1s for windows to show, loop until windows are shown -or 
the test hard stops-. When I ran in my environment, 1s was not enough. This 
should make the test more resilent. We still depend on a timer but that is 
inevitably.

 

 * Incremented the time we wait for the TGs to finish. 2s was not enough in my 
runs. However, we now do frequent checks to finish earlier in the success path.

 

 * Calculated expected value in initilization time

 

 * Changed a bit how the test finishes

  * System.exit(0) is a failure for jtreg

  * We need status -1 for jtreg to detect failures, and will do a hard stop 
when time expires

  * Stack traces for the main thread are not much relevant 

  * dispose window to exit gracefully on the success path

 

 * Removed unused code (button click action)

 

 * Added jtreg tags & copyright

 

Webrev.02 with test integrated:

 

 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02

 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02.zip

 

Kind regards,

Martin.-

 

On Mon, Oct 15, 2018 at 3:38 PM, Laurent Bourgès mailto:bourges.laur...@gmail.com"bourges.laur...@gmail.com> wrote:

Hi Martin,

Thanks for your feedback and happy to hear that it worked!

 

In regards to pendingEvents sync, my understanding is that SequencedEvent 
objects will be posted to one EventQueue only and, thus, be dispatched by one 
EDT.

 

Agreed. 

 

 

I had a quick look at "Exception in thread "AWT-EventQueue-1" 
java.lang.IllegalArgumentException: null source" exception and could not find 
any connection to the code modified in the context of this bug. Apparently, 
"activeWindow" variable in "WindowEvent.WINDOW_LOST_FOCUS" case is null 
(DefaultKeyboardFocusManager.dispatchEvent function). I thought that this was 
caused by the fact that the test is injecting events that modify the focus on 
both windows at a very high rate and, by the time DefaultKeyboardFocusManager 
dispatches the event, it could be too late. Just an hypothesis.

 

I agree, it is certainly a side-effect: other issues may be triggered by such 
event intensive test.

 

Look forward to your re-written test.

 

Here it is:


import java.awt.BorderLayout;
import java.awt.Dimension;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicReference;
import javax.swing.JButton;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.SwingUtilities;
import javax.swing.Timer;

/*
 * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
 * javac --add-exports java.desktop/sun.awt=ALL-UNNAMED TestWinEvent.java
 *
 * @author Laurent Bourges
 */
public final class TestWinEvent extends JFrame implements ActionListener {

    private static final long serialVersionUID = 1L;

    private static final int NUM_WINDOW = 2;
    private static final int INTERVAL = 50;
    private static final int MAX_TIME = 1; // 10s
    private static final int MAX_COUNT = MAX_TIME / INTERVAL;
    private static final List WINDOWS = new 
ArrayList();

    private final JButton btn;
    private int counter = 0;
    private final Timer t;

    public static void main(String[] args) {
    try {
    for (int i = 0; i < NUM_WINDOW; i++) {
    createWin(i + 1);
    }

    // Wait MAX_TIME + 2s
    Thread.sleep(MAX_TIME + 2000);

    int total = 0;
    for (TestWinEvent window : WINDOWS) {
    total += window.get

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Krishna,

A complete fix was found in another thread:
http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014442.html

Laurent

Le mer. 3 oct. 2018 à 18:26, Laurent Bourgès  a
écrit :

> Hi Krishna,
>
> I applied the patch on latest OpenJDK12 client and it works well with my
> reproducer test.
>
> I am really puzzled by this 'One Line' change that seems causing my
> troubles:
> ID != SentEvent.ID, so it can explain why AWT was waiting on wrong event
> ID then hanging for ever !
>
> -edt.pumpEvents(ID, () ->
> !SequencedEvent.this.isFirstOrDisposed());
> +edt.pumpEvents(SentEvent.ID, () ->
> !SequencedEvent.this.isFirstOrDisposed());
>
> PS: I can no more test with IcedTea-Web as my patch has been merged.
>
> Laurent
>
> Le mer. 3 oct. 2018 à 14:11, Krishna Addepalli <
> krishna.addepa...@oracle.com> a écrit :
>
>> Hi Laurent,
>>
>>
>>
>> Sorry, I could not get to the root cause yet. Seems like it might take
>> some time and some hard debugging.
>>
>>
>>
>> Meanwhile, I’m attaching a simple patch file which effectively reverts
>> the earlier fix that was done for JDK-8152974.
>>
>> Please try this and let me know if this solves your problem. Then I’ll
>> create a backout bug and push this patch.
>>
>>
>>
>> Thanks,
>>
>> Krishna
>>
>>
>>
>> *From:* Laurent Bourgès 
>> *Sent:* Thursday, September 27, 2018 12:57 PM
>> *To:* Krishna Addepalli 
>> *Cc:* Phil Race ; Sergey Bylokhov <
>> sergey.bylok...@oracle.com>; awt-dev@openjdk.java.net
>> *Subject:* Re:  OpenJdk11-28-EA JDialog hanging
>>
>>
>>
>> Any progress on this bug, krishna ?
>>
>>
>>
>> At least could you explain how SequencedEvent should be processed when
>> multiple AppContexts are present ?
>>
>>
>>
>> I could help but I have no clue what's going on ... I observed multiple
>> several EDT, AppContexts, awt events, it is very complicated to understand
>> such event handling.
>>
>>
>>
>> Cheers,
>>
>> Laurent
>>
>>
>>
>> Le jeu. 6 sept. 2018 à 18:02, Laurent Bourgès 
>> a écrit :
>>
>> Hi Krishna,
>>
>> Le jeu. 6 sept. 2018 à 16:08, Krishna Addepalli <
>> krishna.addepa...@oracle.com> a écrit :
>>
>> Hi Laurent,
>>
>>
>>
>> Thanks for providing the test case. I was able to reproduce the issue.
>> Glad to know that you found a workaround, as this issue is a bit tricky to
>> fix.
>>
>> Great.
>>
>>
>>
>> Meanwhile, I’m looking into fixing this issue, and your test case greatly
>> helps me toward finding the fix faster.
>>
>>
>>
>> I tried diagnosing the bug in EDT/SequencedEvent using heap dumps ... but
>> I got no clues, very tricky.
>>
>>
>>
>> Good luck,
>>
>> Laurent
>>
>>
>>
>>
>
> --
> --
> Laurent Bourgès
>

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Sergey,

Could you have a look as this fix is important for IcedTeaWeb + jdk11 ?

The webrev applies to OpenJDK12 but should be backported to 11 ?

TimeFrame for 11.0.2 RDP2: late october, GA late january

Cheers,
Laurent

Le mar. 16 oct. 2018 à 15:50, Laurent Bourgès  a
écrit :

> Hi Martin,
>
> Thanks for your test! Great job :-)
>>
>
> Thanks, your fixes are good.
>
>
>> I applied some minor changes for integration:
>>
>>  * Renamed to TestSeqEventsMultipleContexts
>>   * A bit longer but should describe what this is about
>>   * Placed in jdk/java/awt/event/SequencedEvent
>>
>>  * Encapsulated the window in TestWindow class
>>
>>  * Instead of waiting 1s for windows to show, loop until windows are
>> shown -or the test hard stops-. When I ran in my environment, 1s was not
>> enough. This should make the test more resilent. We still depend on a timer
>> but that is inevitably.
>>
>>  * Incremented the time we wait for the TGs to finish. 2s was not enough
>> in my runs. However, we now do frequent checks to finish earlier in the
>> success path.
>>
>>  * Calculated expected value in initilization time
>>
>>  * Changed a bit how the test finishes
>>   * System.exit(0) is a failure for jtreg
>>   * We need status -1 for jtreg to detect failures, and will do a hard
>> stop when time expires
>>   * Stack traces for the main thread are not much relevant
>>   * dispose window to exit gracefully on the success path
>>
>>  * Removed unused code (button click action)
>>
>>  * Added jtreg tags & copyright
>>
>> Webrev.02 with test integrated:
>>
>>  * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02
>>  *
>> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02.zip
>>
>
> I tested the new TestSeqEventsMultipleContexts:
> - jdk8/9/10: OK
> - jdk11: KO
> - jdk12+patch: OK
>
> I am not an awt reviewer, but it is OK for me.
>
> Cheers,
> Laurent
>

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,

Thanks for your test! Great job :-)
>

Thanks, your fixes are good.


> I applied some minor changes for integration:
>
>  * Renamed to TestSeqEventsMultipleContexts
>   * A bit longer but should describe what this is about
>   * Placed in jdk/java/awt/event/SequencedEvent
>
>  * Encapsulated the window in TestWindow class
>
>  * Instead of waiting 1s for windows to show, loop until windows are shown
> -or the test hard stops-. When I ran in my environment, 1s was not enough.
> This should make the test more resilent. We still depend on a timer but
> that is inevitably.
>
>  * Incremented the time we wait for the TGs to finish. 2s was not enough
> in my runs. However, we now do frequent checks to finish earlier in the
> success path.
>
>  * Calculated expected value in initilization time
>
>  * Changed a bit how the test finishes
>   * System.exit(0) is a failure for jtreg
>   * We need status -1 for jtreg to detect failures, and will do a hard
> stop when time expires
>   * Stack traces for the main thread are not much relevant
>   * dispose window to exit gracefully on the success path
>
>  * Removed unused code (button click action)
>
>  * Added jtreg tags & copyright
>
> Webrev.02 with test integrated:
>
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02
>  *
> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02.zip
>

I tested the new TestSeqEventsMultipleContexts:
- jdk8/9/10: OK
- jdk11: KO
- jdk12+patch: OK

I am not an awt reviewer, but it is OK for me.

Cheers,
Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Laurent,

Thanks for your test! Great job :-)

I applied some minor changes for integration:

 * Renamed to TestSeqEventsMultipleContexts
  * A bit longer but should describe what this is about
  * Placed in jdk/java/awt/event/SequencedEvent

 * Encapsulated the window in TestWindow class

 * Instead of waiting 1s for windows to show, loop until windows are shown
-or the test hard stops-. When I ran in my environment, 1s was not enough.
This should make the test more resilent. We still depend on a timer but
that is inevitably.

 * Incremented the time we wait for the TGs to finish. 2s was not enough in
my runs. However, we now do frequent checks to finish earlier in the
success path.

 * Calculated expected value in initilization time

 * Changed a bit how the test finishes
  * System.exit(0) is a failure for jtreg
  * We need status -1 for jtreg to detect failures, and will do a hard stop
when time expires
  * Stack traces for the main thread are not much relevant
  * dispose window to exit gracefully on the success path

 * Removed unused code (button click action)

 * Added jtreg tags & copyright

Webrev.02 with test integrated:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02
 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02.zip

Kind regards,
Martin.-

On Mon, Oct 15, 2018 at 3:38 PM, Laurent Bourgès 
wrote:

> Hi Martin,
>
>> Thanks for your feedback and happy to hear that it worked!
>>
>> In regards to pendingEvents sync, my understanding is that
>> SequencedEvent objects will be posted to one EventQueue only and, thus, be
>> dispatched by one EDT.
>>
>
> Agreed.
>
>
>> I had a quick look at "Exception in thread "AWT-EventQueue-1" 
>> java.lang.IllegalArgumentException:
>> null source" exception and could not find any connection to the code
>> modified in the context of this bug. Apparently, "activeWindow" variable in
>> "WindowEvent.WINDOW_LOST_FOCUS" case is null
>> (DefaultKeyboardFocusManager.dispatchEvent function). I thought that
>> this was caused by the fact that the test is injecting events that modify
>> the focus on both windows at a very high rate and, by the time
>> DefaultKeyboardFocusManager dispatches the event, it could be too late.
>> Just an hypothesis.
>>
>
> I agree, it is certainly a side-effect: other issues may be triggered by
> such event intensive test.
>
>
>> Look forward to your re-written test.
>>
>
> Here it is:
>
> import java.awt.BorderLayout;
> import java.awt.Dimension;
> import java.awt.event.ActionEvent;
> import java.awt.event.ActionListener;
> import java.util.ArrayList;
> import java.util.List;
> import java.util.concurrent.atomic.AtomicReference;
> import javax.swing.JButton;
>
> import javax.swing.JFrame;
> import javax.swing.JLabel;
> import javax.swing.SwingUtilities;
> import javax.swing.Timer;
>
> /*
>  * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
>  * javac --add-exports java.desktop/sun.awt=ALL-UNNAMED TestWinEvent.java
>  *
>  * @author Laurent Bourges
>  */
> public final class TestWinEvent extends JFrame implements ActionListener {
>
> private static final long serialVersionUID = 1L;
>
> private static final int NUM_WINDOW = 2;
> private static final int INTERVAL = 50;
> private static final int MAX_TIME = 1; // 10s
> private static final int MAX_COUNT = MAX_TIME / INTERVAL;
> private static final List WINDOWS = new
> ArrayList();
>
> private final JButton btn;
> private int counter = 0;
> private final Timer t;
>
> public static void main(String[] args) {
> try {
> for (int i = 0; i < NUM_WINDOW; i++) {
> createWin(i + 1);
> }
>
> // Wait MAX_TIME + 2s
> Thread.sleep(MAX_TIME + 2000);
>
> int total = 0;
> for (TestWinEvent window : WINDOWS) {
> total += window.getCounter();
> }
>
> // Failure if AWT hanging: assert
> final int expected = MAX_COUNT * NUM_WINDOW;
> if (total != expected) {
> throw new IllegalStateException("Total [" + total + "] !=
> expected [" + expected + "] !");
> }
> } catch (InterruptedException ie) {
> ie.printStackTrace();
> } catch (IllegalStateException iae) {
> iae.printStackTrace();
> } finally {
> System.exit(0);
> }
> }
>
> private static void createWin(int tgNum) {
> new Thread(new ThreadGroup("TG " + tgNum),
> new Runnable() {
> @Override
> public void run() {
> sun.awt.SunToolkit.createNewAppContext();
>
> final AtomicReference ref = new
> AtomicReference();
>
> SwingUtilities.invokeLater(new Runnable() {
> @Override
> public void run() {
> final TestWinEvent window = new
> TestWin

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,

> Thanks for your feedback and happy to hear that it worked!
>
> In regards to pendingEvents sync, my understanding is that SequencedEvent
> objects will be posted to one EventQueue only and, thus, be dispatched by
> one EDT.
>

Agreed.


> I had a quick look at "Exception in thread "AWT-EventQueue-1"
> java.lang.IllegalArgumentException: null source" exception and could not
> find any connection to the code modified in the context of this bug.
> Apparently, "activeWindow" variable in "WindowEvent.WINDOW_LOST_FOCUS" case
> is null (DefaultKeyboardFocusManager.dispatchEvent function). I thought
> that this was caused by the fact that the test is injecting events that
> modify the focus on both windows at a very high rate and, by the time 
> DefaultKeyboardFocusManager
> dispatches the event, it could be too late. Just an hypothesis.
>

I agree, it is certainly a side-effect: other issues may be triggered by
such event intensive test.


> Look forward to your re-written test.
>

Here it is:

import java.awt.BorderLayout;
import java.awt.Dimension;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicReference;
import javax.swing.JButton;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.SwingUtilities;
import javax.swing.Timer;

/*
 * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
 * javac --add-exports java.desktop/sun.awt=ALL-UNNAMED TestWinEvent.java
 *
 * @author Laurent Bourges
 */
public final class TestWinEvent extends JFrame implements ActionListener {

private static final long serialVersionUID = 1L;

private static final int NUM_WINDOW = 2;
private static final int INTERVAL = 50;
private static final int MAX_TIME = 1; // 10s
private static final int MAX_COUNT = MAX_TIME / INTERVAL;
private static final List WINDOWS = new
ArrayList();

private final JButton btn;
private int counter = 0;
private final Timer t;

public static void main(String[] args) {
try {
for (int i = 0; i < NUM_WINDOW; i++) {
createWin(i + 1);
}

// Wait MAX_TIME + 2s
Thread.sleep(MAX_TIME + 2000);

int total = 0;
for (TestWinEvent window : WINDOWS) {
total += window.getCounter();
}

// Failure if AWT hanging: assert
final int expected = MAX_COUNT * NUM_WINDOW;
if (total != expected) {
throw new IllegalStateException("Total [" + total + "] !=
expected [" + expected + "] !");
}
} catch (InterruptedException ie) {
ie.printStackTrace();
} catch (IllegalStateException iae) {
iae.printStackTrace();
} finally {
System.exit(0);
}
}

private static void createWin(int tgNum) {
new Thread(new ThreadGroup("TG " + tgNum),
new Runnable() {
@Override
public void run() {
sun.awt.SunToolkit.createNewAppContext();

final AtomicReference ref = new
AtomicReference();

SwingUtilities.invokeLater(new Runnable() {
@Override
public void run() {
final TestWinEvent window = new TestWinEvent(tgNum);
window.setVisible(true);
ref.set(window);
WINDOWS.add(window);
}
});

try {
// Wait 1s to show window
Thread.sleep(1000);
} catch (InterruptedException ie) {
ie.printStackTrace();
}

final TestWinEvent window = ref.get();
if (window != null) {
window.enableTimer(true);
}
}
}).start();
}

TestWinEvent(final int num) {
super("Test Window [" + num + "]");
setMinimumSize(new Dimension(300, 200));
setLocation(100 + 400 * (num - 1), 100);

setLayout(new BorderLayout());
JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
add(textBlock);

btn = new JButton("TEST");
btn.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
System.out.println("Button#" + num + " clicked: " +
counter);
}

});
add(btn, BorderLayout.SOUTH);

setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
pack();

t = new Timer(INTERVAL, this);
t.setRepeats(false);
}

@Override
public void actionPerformed(ActionEvent e) {
this.toFront();
btn.setText("TEST " + (++counter));
this.toBack();
if (counter < MAX_COUNT) {

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Laurent,

Thanks for your feedback and happy to hear that it worked!

In regards to pendingEvents sync, my understanding is that SequencedEvent
objects will be posted to one EventQueue only and, thus, be dispatched by
one EDT.

I had a quick look at "Exception in thread "AWT-EventQueue-1"
java.lang.IllegalArgumentException: null source" exception and could not
find any connection to the code modified in the context of this bug.
Apparently, "activeWindow" variable in "WindowEvent.WINDOW_LOST_FOCUS" case
is null (DefaultKeyboardFocusManager.dispatchEvent function). I thought
that this was caused by the fact that the test is injecting events that
modify the focus on both windows at a very high rate and, by the time
DefaultKeyboardFocusManager
dispatches the event, it could be too late. Just an hypothesis.

Look forward to your re-written test.

Kind regards,
Martin.-

On Fri, Oct 12, 2018 at 6:03 PM, Laurent Bourgès 
wrote:

> Martin,
>
> The reproducer test works now on OpenJDK12 + 8204142.webrev.01 patch !
> I also tested with 4 windows and it is OK.
>
> One minor bug that appears in my logs, it is certainly related to your fix
> as I never had that message on JDK8:
> Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException:
> null source
> at java.base/java.util.EventObject.(EventObject.java:56)
> at java.desktop/java.awt.AWTEvent.(AWTEvent.java:317)
> at java.desktop/java.awt.event.ComponentEvent.(
> ComponentEvent.java:120)
> at java.desktop/java.awt.event.WindowEvent.(
> WindowEvent.java:206)
> at java.desktop/java.awt.event.WindowEvent.(
> WindowEvent.java:251)
> at java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchEvent(
> DefaultKeyboardFocusManager.java:820)
> at java.desktop/java.awt.Component.dispatchEventImpl(
> Component.java:4889)
> at java.desktop/java.awt.Container.dispatchEventImpl(
> Container.java:2321)
> at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2762)
> at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
> at java.desktop/java.awt.EventQueue.dispatchEventImpl(
> EventQueue.java:772)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
> at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.
> doIntersectionPrivilege(ProtectionDomain.java:85)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.
> doIntersectionPrivilege(ProtectionDomain.java:95)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
> at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.
> doIntersectionPrivilege(ProtectionDomain.java:85)
> at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
> at java.desktop/java.awt.SequencedEvent.dispatch(
> SequencedEvent.java:201)
> at java.desktop/java.awt.EventQueue.dispatchEventImpl(
> EventQueue.java:770)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
> at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
> at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.
> doIntersectionPrivilege(ProtectionDomain.java:85)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.
> doIntersectionPrivilege(ProtectionDomain.java:95)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
> at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
> at java.base/java.security.AccessController.doPrivileged(Native
> Method)
> at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.
> doIntersectionPrivilege(ProtectionDomain.java:85)
> at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
> at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(
> EventDispatchThread.java:203)
> at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(
> EventDispatchThread.java:124)
> at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(
> EventDispatchThread.java:113)
> at java.desktop/java.awt.EventDispatchThread.pumpEvents(
> EventDispatchThread.java:109)
> at java.desktop/java.awt.EventDispatchThread.pumpEvents(
> EventDispatchThread.java:101)
> at java.desktop/java.awt.EventDispatchThread.run(
> EventDispatchThread.java:90)
>
> Congratulations,
> Laurent
>
> Le ven. 12 oct. 2018 à 17:24, Laurent Bourgès 
> a écrit :
>
>> Hi Martin,
>>
>> What an amazing effort !
>> I am very pleased that my (crazy) test triggered a very complicated case;
>> I will try asap if it works with your new webrev.
>>
>> Thanks for your feedback and sha

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Martin,

The reproducer test works now on OpenJDK12 + 8204142.webrev.01 patch !
I also tested with 4 windows and it is OK.

One minor bug that appears in my logs, it is certainly related to your fix
as I never had that message on JDK8:
Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException:
null source
at java.base/java.util.EventObject.(EventObject.java:56)
at java.desktop/java.awt.AWTEvent.(AWTEvent.java:317)
at
java.desktop/java.awt.event.ComponentEvent.(ComponentEvent.java:120)
at java.desktop/java.awt.event.WindowEvent.(WindowEvent.java:206)
at java.desktop/java.awt.event.WindowEvent.(WindowEvent.java:251)
at
java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:820)
at
java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4889)
at
java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2762)
at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
at
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at
java.desktop/java.awt.SequencedEvent.dispatch(SequencedEvent.java:201)
at
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:95)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:745)
at java.desktop/java.awt.EventQueue$5.run(EventQueue.java:743)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
at
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

Congratulations,
Laurent

Le ven. 12 oct. 2018 à 17:24, Laurent Bourgès  a
écrit :

> Hi Martin,
>
> What an amazing effort !
> I am very pleased that my (crazy) test triggered a very complicated case;
> I will try asap if it works with your new webrev.
>
> Thanks for your feedback and sharing your test.
>>
>> I've taken your suggestion of making the filter class final. In regards
>> to having a single instance of the filter class, it would have been a good
>> idea but now we have some additional requirements you'll see below.
>>
>> I could reproduce your deadlock. This deadlock scenario is a bit more
>> interesting than the one fixed in Webrev00.
>>
>> At some point, we may reach the following state:
>>
>> SequenceEvent.list: EV0-AppContext1, EV0-AppContext0, EV1-AppContext0
>> EventQueue0: EV0-AppContext0, EV1-AppContext0
>>
>> EDT0 now takes EV0-AppContext0 out of EventQueue0. When dispatching this
>> event, it notices that it's not the first one in SequenceEvent.list and
>> proceeds to dispatch a new event from EventQueue0 while waiting. It gets
>> EV1-AppContext0 and again, it cannot continue because EV0-AppContext1 is
>> still the first one in SequenceEvent.list. EDT0 now waits for either a
>> SentEvent (sent by EDT1) or for a new SequencedEvent in EventQueue0.
>>
>> Let's say that EDT1 dispatches EV0-AppContext1 and sends a SentEvent to
>> EDT0. EDT0 wakes up (enabled at Webrev00) a

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,

What an amazing effort !
I am very pleased that my (crazy) test triggered a very complicated case; I
will try asap if it works with your new webrev.

Thanks for your feedback and sharing your test.
>
> I've taken your suggestion of making the filter class final. In regards to
> having a single instance of the filter class, it would have been a good
> idea but now we have some additional requirements you'll see below.
>
> I could reproduce your deadlock. This deadlock scenario is a bit more
> interesting than the one fixed in Webrev00.
>
> At some point, we may reach the following state:
>
> SequenceEvent.list: EV0-AppContext1, EV0-AppContext0, EV1-AppContext0
> EventQueue0: EV0-AppContext0, EV1-AppContext0
>
> EDT0 now takes EV0-AppContext0 out of EventQueue0. When dispatching this
> event, it notices that it's not the first one in SequenceEvent.list and
> proceeds to dispatch a new event from EventQueue0 while waiting. It gets
> EV1-AppContext0 and again, it cannot continue because EV0-AppContext1 is
> still the first one in SequenceEvent.list. EDT0 now waits for either a
> SentEvent (sent by EDT1) or for a new SequencedEvent in EventQueue0.
>
> Let's say that EDT1 dispatches EV0-AppContext1 and sends a SentEvent to
> EDT0. EDT0 wakes up (enabled at Webrev00) and tries to dispatch
> EV1-AppContext0. However, EV1-AppContext0 is not the first one in
> SequenceEvent.list so it goes to sleep again (waiting for a SentEvent or a
> new SequencedEvent to come).
>
> However, EDT0 is the only one that can unlock this by dispatching
> EV0-AppContext0. This is not possible because EV0-AppContext0-dispatch call
> is down the stack. There is a stack frame on top of it: the one for
> EV1-AppContext0-dispatch. It's an inversion of the order.
>
> We don't want EDT0 to take a new SequencedEvent out of EventQueue0 (that
> is: creating a new dispatch frame on the call stack) if all events in
> SequenceEvent.list previous to the currently SequencedEvent event being
> dispatched are from a different AppContext.
>
> My first approach to this was: check SequenceEvent.list before going to
> sleep and see if we need to filter SequencedEvent events or not. However,
> this does not work for 2 reasons:
>
>  1) Events in SequencedEvent.list which are not being dispatched have a
> null AppContext. The only way of knowing if they belong to a specific
> AppContext is by iterating the EventeQueue queue and checking object
> identity. No APIs for this. On the other hand, assigning an AppContext when
> creating SequencedEvent events may break things (i.e.: creating events on a
> TG and posting them to a different one).
>
>  2) We cannot loose SequencedEvent events. Of course.
>
> What I propose to do is capturing out-of-order SequencedEvents events in
> the filter and releasing them once we dispatch the frame. In other words,
> try to dispatch only if the event that arrives is from a previous position
> in SequenceEvent.list (so we won't block).
>
> In addition to these changes, I propose to dispatch any non-SequencedEvent
> event while waiting. There is no need to block other events, and the GUI
> becomes unresponsive under a stress case such as the test otherwise.
>
> Removed an unnecessary "wakeup" on SequencedEvent.dispose function.
>
> Webrev 01:
>
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.01/
>  *
> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.01.zip
>

I had a quick look to the patch.
I noticed that the list pendingEvents is not synchronized and I wonder if
multiple EDT threads may be working on the same SequencedEvent:
- currentSequencedEvent.pendingEvents.add(ev);
- for(AWTEvent e : pendingEvents) { SunToolkit.postEvent(appContext, e); }

I suppose it should never happen, so synchronization is useless !

@Laurent: is it possible to tweak your test a bit to remove internal API
> usage and include an assertion? I don't know if you have tried that before,
> but it would be very nice so we can include your test in the patch. One
> additional comment regarding the test: the 10 ms lapse between events
> injection it is too fast for dispatching to keep up with -at least in my
> environment-; the queue tends to grow in the long run. 100 ms made it
> stable. I don't expect this test to run for too much though.
>

Good idea, I will try rewriting the test.

Regards,
Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi Laurent,

Thanks for your feedback and sharing your test.

I've taken your suggestion of making the filter class final. In regards to
having a single instance of the filter class, it would have been a good
idea but now we have some additional requirements you'll see below.

I could reproduce your deadlock. This deadlock scenario is a bit more
interesting than the one fixed in Webrev00.

At some point, we may reach the following state:

SequenceEvent.list: EV0-AppContext1, EV0-AppContext0, EV1-AppContext0
EventQueue0: EV0-AppContext0, EV1-AppContext0

EDT0 now takes EV0-AppContext0 out of EventQueue0. When dispatching this
event, it notices that it's not the first one in SequenceEvent.list and
proceeds to dispatch a new event from EventQueue0 while waiting. It gets
EV1-AppContext0 and again, it cannot continue because EV0-AppContext1 is
still the first one in SequenceEvent.list. EDT0 now waits for either a
SentEvent (sent by EDT1) or for a new SequencedEvent in EventQueue0.

Let's say that EDT1 dispatches EV0-AppContext1 and sends a SentEvent to
EDT0. EDT0 wakes up (enabled at Webrev00) and tries to dispatch
EV1-AppContext0. However, EV1-AppContext0 is not the first one in
SequenceEvent.list so it goes to sleep again (waiting for a SentEvent or a
new SequencedEvent to come).

However, EDT0 is the only one that can unlock this by dispatching
EV0-AppContext0. This is not possible because EV0-AppContext0-dispatch call
is down the stack. There is a stack frame on top of it: the one for
EV1-AppContext0-dispatch. It's an inversion of the order.

We don't want EDT0 to take a new SequencedEvent out of EventQueue0 (that
is: creating a new dispatch frame on the call stack) if all events in
SequenceEvent.list previous to the currently SequencedEvent event being
dispatched are from a different AppContext.

My first approach to this was: check SequenceEvent.list before going to
sleep and see if we need to filter SequencedEvent events or not. However,
this does not work for 2 reasons:

 1) Events in SequencedEvent.list which are not being dispatched have a
null AppContext. The only way of knowing if they belong to a specific
AppContext is by iterating the EventeQueue queue and checking object
identity. No APIs for this. On the other hand, assigning an AppContext when
creating SequencedEvent events may break things (i.e.: creating events on a
TG and posting them to a different one).

 2) We cannot loose SequencedEvent events. Of course.

What I propose to do is capturing out-of-order SequencedEvents events in
the filter and releasing them once we dispatch the frame. In other words,
try to dispatch only if the event that arrives is from a previous position
in SequenceEvent.list (so we won't block).

In addition to these changes, I propose to dispatch any non-SequencedEvent
event while waiting. There is no need to block other events, and the GUI
becomes unresponsive under a stress case such as the test otherwise.

Removed an unnecessary "wakeup" on SequencedEvent.dispose function.

Webrev 01:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.01/
 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.01.zip

Can I have a review for it?

@Laurent: is it possible to tweak your test a bit to remove internal API
usage and include an assertion? I don't know if you have tried that before,
but it would be very nice so we can include your test in the patch. One
additional comment regarding the test: the 10 ms lapse between events
injection it is too fast for dispatching to keep up with -at least in my
environment-; the queue tends to grow in the long run. 100 ms made it
stable. I don't expect this test to run for too much though.

Kind regards,
Martin.-

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,

Sorry to tell you that your patch does not fix the reproducer test I made
(see at the end).
It is expected that 2 windows have their corresponding buttons "TEST "
animated:  is incrementing, showing events are properly propagated
among windows (2 AppContexts).

I added few logs in the SequencedEventFilter (accept ids) and reject, and
it seems SequencedEvent are still blocking the EDT queues (sort of
deadlock):
SequencedEventsFilter.acceptEvent: reject id = 1200
SequencedEventsFilter.acceptEvent: id = 1006
SequencedEventsFilter.acceptEvent: id = 1006
SequencedEventsFilter.acceptEvent: id = 1006
SequencedEventsFilter.acceptEvent: id = 1007
SequencedEventsFilter.acceptEvent: reject id = 1200
SequencedEventsFilter.acceptEvent: id = 1007
SequencedEventsFilter.acceptEvent: id = 1007
SequencedEventsFilter.acceptEvent: id = 1007
SequencedEventsFilter.acceptEvent: reject id = 800
SequencedEventsFilter.acceptEvent: id = 1007
SequencedEventsFilter.acceptEvent: reject id = 800
SequencedEventsFilter.acceptEvent: reject id = 1200
SequencedEventsFilter.acceptEvent: id = 1006
...

My modified patch:
--- a/src/java.desktop/share/classes/java/awt/SequencedEvent.java   Wed
Oct 10 16:20:52 2018 +0530
+++ b/src/java.desktop/share/classes/java/awt/SequencedEvent.java   Wed
Oct 10 21:15:26 2018 +0200
@@ -81,6 +81,20 @@
 });
 }

+private static final class SequencedEventsFilter implements
EventFilter {
+private static final SequencedEventsFilter INSTANCE = new
SequencedEventsFilter();
+@Override
+public FilterAction acceptEvent(AWTEvent ev) {
+final int eventID = ev.getID();
+if (eventID == ID || eventID == SentEvent.ID) {
+System.out.println("SequencedEventsFilter.acceptEvent: id = "+eventID);
+return FilterAction.ACCEPT;
+}
+System.out.println("SequencedEventsFilter.acceptEvent: reject id =
"+eventID);
+return FilterAction.REJECT;
+}
+}
+
 /**
  * Constructs a new SequencedEvent which will dispatch the specified
  * nested event.
@@ -135,7 +149,8 @@
 if (Thread.currentThread() instanceof
EventDispatchThread) {
 EventDispatchThread edt = (EventDispatchThread)
 Thread.currentThread();
-edt.pumpEvents(ID, () ->
!SequencedEvent.this.isFirstOrDisposed());
+edt.pumpEventsForFilter(() ->
!SequencedEvent.this.isFirstOrDisposed(),
+SequencedEventsFilter.INSTANCE);
 } else {
 if (fxAppThreadIsDispatchThread) {
 fxCheckSequenceThread.start();

Kind Regards,
Laurent

PS: the reproducer TestWinEvent class:

import java.awt.AWTEvent;
import java.awt.BorderLayout;
import java.awt.Dimension;
import java.awt.Toolkit;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.WindowEvent;
import java.lang.reflect.Constructor;
import javax.swing.JButton;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.SwingUtilities;
import javax.swing.Timer;
import sun.awt.AppContext;
import sun.awt.SunToolkit;

/*
 * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
 * @author Laurent Bourges
 */
public class TestWinEvent extends JFrame implements ActionListener {

private static final long serialVersionUID = 1L;

private int counter = 0;
private JButton btn;

public static void main(String[] args) {
createWin(1);
createWin(2);
}

private static void createWin(int tgNum) {
ThreadGroup tg = new ThreadGroup("TG " + tgNum);

Thread t = new Thread(tg, new Runnable() {
public void run() {
AppContext context = SunToolkit.createNewAppContext();

SwingUtilities.invokeLater(new Runnable() {
public void run() {
final TestWinEvent window = new TestWinEvent(tgNum);
window.setVisible(true);

new Timer(10, window).start();
}
});
}
});
t.start();
}

public TestWinEvent(final int num) {
super("Test Window + " + num);
setMinimumSize(new Dimension(300, 200));
setLocation(100 + 400 * (num - 1), 100);

setLayout(new BorderLayout());
JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
add(textBlock);

btn = new JButton("TEST");
btn.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
System.out.println("Button#" + num + " clicked: " +
counter);
}

});
add(btn, BorderLayout.SOUTH);

setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
pack();
}

@Override
public voi

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Martin,

I am not a reviewer, but I will test your fix with the reproducer test I
wrote for this bug.
Did you try it ? I will do asap.

You should use a single instance for your SequencedEventFilter and make
this class final:
private static final class SequencedEventsFilter implements EventFilter
{
+ private static final SequencedEventsFilter INSTANCE = new
SequencedEventsFilter();
Then
edt.pumpEventsForFilter(() ->
!SequencedEvent.this.isFirstOrDisposed(),
+new SequencedEventsFilter());
=> SequencedEventsFilter.INSTANCE);

I noticed your patch do not provide any test... yet ?
I think it is needed here.

Good job for your detailed analysis and the webrev.

Regards,
Laurent

Le mer. 10 oct. 2018 à 18:19, Martin Balao  a écrit :

> Hi,
>
> Can I have a review for JDK-8204142 [1] Webrev 00?
>
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.00/
>  *
> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.00.zip
>
> As a result of [2], I propose Event Dispatch Threads to be aware of
> SentEvent AWT events when sleeping.
>
> In the tests I did, the SequencedEvent.list is successfully flushed with
> this patch.
>
> Thanks,
> Martin.-
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8204142
> [2] -
> http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014426.html
>


-- 
-- 
Laurent Bourgès

OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi,

Can I have a review for JDK-8204142 [1] Webrev 00?

 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.00/
 * http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.00.zip

As a result of [2], I propose Event Dispatch Threads to be aware of
SentEvent AWT events when sleeping.

In the tests I did, the SequencedEvent.list is successfully flushed with
this patch.

Thanks,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8204142
[2] -
http://mail.openjdk.java.net/pipermail/awt-dev/2018-October/014426.html

OpenJdk11-28-EA JDialog hanging

[Martin Balao]

Hi all,

I was not sure if my runs of SequencedEventTest test were triggering the
problematic execution flow, because this issue should manifest even after
JDK-8152974 [1] fix. After a few tries I attached a debugger. Attaching a
debugger obviously interferred with robot steps on the test but, anyways,
handled it and reproduced the problem.

I had a quick look and this is my hypothesis for JDK-8204142 [2] issue:

Let's say we have EDT0 (EventQueue0, AppContext0) and EDT1 (EventQueue1,
AppContext1). Both threads are dispatching events from their respective
EventQueue queues. In particular, dispatching SequencedEvent events. We
also have SequencedEvent.list list, in which SequencedEvent events from
both AppContext0 and AppContext1 are interleaved. These SequencedEvent
events will be dispatched by both EDT0 and EDT1 (EDT0 dispatching
AppContext0 events from EventQueue0 and EDT1 dispatching AppContext1 events
from EventQueue1).

Now, we may have the following sequence of events in the
SequencedEvent.list queue: EV0-AppContext0, EV0-AppContext1,
EV1-AppContext1, EV1-AppContext0. Events, though, may come to EventQueue
queues out of order (I.e: EventQueue1 may have EV1-AppContext1 first and
EV0-AppContext1 then, while EventQueue0 may have EV0-AppContext0 first and
EV1-AppContext0 then).

In the previous scenario, EDT1 will try to dispatch EV1-AppContext1 first.
However, it notices that it is not the first event in the
SequencedEvent.list queue. After JDK-8152974 [1] fix, EDT1 will try to
dispatch other SequencedEvents from his EventQueue queue. So it goes
straight to EV0-AppContext1, which is the next one in EventQueue1. It
notices that this is not the first event in SequencedEvent.list queue and
tries to do the same. However, no more SequencedEvents are available for
him to dispatch (no more SequencedEvents in EventQueue1). It will then
block indefinitely waiting for SequencedEvents to come to EventQueue1. Now
it's time for EDT0. EDT0 will successfully dispatch EV0-AppContext0 and
then try to dispatch EV1-AppContext0. When trying to dispatch the latter,
it will notice that it is not the first one in SequencedEvent.list queue
and blocks the same way EDT1 did before. Now we have both EDT0 and EDT1
blocked waiting for SequencedEvent events to come to their respective
EventQueue queues. EDT1 should have woken up and proceeded dispatching
EV0-AppContext1.

The underlying problem is that SequencedEvent.dispatch function is not
prepared for SequencedEvent.list list to have events from different
EventQueue queues, dispatched by different EDTs. The assumption that if the
event is not the first one on SequencedEvent.list list we will successfully
be able to dispatch an event from the EventQueue and unblock the sequence
is wrong. We may wait for this event indefinitely and, at some point, we
will be the ones blocking the whole thing because our event now is the
first one. Please note here that the wake-up scheme in
SequencedEvent.dispose function fails because it's sending SentEvent events
and the waiting thread (after JDK-8152974 [1]) is filtering SequencedEvent
events.

Kind regards,
Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8152974
[2] - https://bugs.openjdk.java.net/browse/JDK-8204142

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Krishna,

I applied the patch on latest OpenJDK12 client and it works well with my
reproducer test.

I am really puzzled by this 'One Line' change that seems causing my
troubles:
ID != SentEvent.ID, so it can explain why AWT was waiting on wrong event ID
then hanging for ever !

-edt.pumpEvents(ID, () ->
!SequencedEvent.this.isFirstOrDisposed());
+edt.pumpEvents(SentEvent.ID, () ->
!SequencedEvent.this.isFirstOrDisposed());

PS: I can no more test with IcedTea-Web as my patch has been merged.

Laurent

Le mer. 3 oct. 2018 à 14:11, Krishna Addepalli 
a écrit :

> Hi Laurent,
>
>
>
> Sorry, I could not get to the root cause yet. Seems like it might take
> some time and some hard debugging.
>
>
>
> Meanwhile, I’m attaching a simple patch file which effectively reverts the
> earlier fix that was done for JDK-8152974.
>
> Please try this and let me know if this solves your problem. Then I’ll
> create a backout bug and push this patch.
>
>
>
> Thanks,
>
> Krishna
>
>
>
> *From:* Laurent Bourgès 
> *Sent:* Thursday, September 27, 2018 12:57 PM
> *To:* Krishna Addepalli 
> *Cc:* Phil Race ; Sergey Bylokhov <
> sergey.bylok...@oracle.com>; awt-dev@openjdk.java.net
> *Subject:* Re:  OpenJdk11-28-EA JDialog hanging
>
>
>
> Any progress on this bug, krishna ?
>
>
>
> At least could you explain how SequencedEvent should be processed when
> multiple AppContexts are present ?
>
>
>
> I could help but I have no clue what's going on ... I observed multiple
> several EDT, AppContexts, awt events, it is very complicated to understand
> such event handling.
>
>
>
> Cheers,
>
> Laurent
>
>
>
> Le jeu. 6 sept. 2018 à 18:02, Laurent Bourgès 
> a écrit :
>
> Hi Krishna,
>
> Le jeu. 6 sept. 2018 à 16:08, Krishna Addepalli <
> krishna.addepa...@oracle.com> a écrit :
>
> Hi Laurent,
>
>
>
> Thanks for providing the test case. I was able to reproduce the issue.
> Glad to know that you found a workaround, as this issue is a bit tricky to
> fix.
>
> Great.
>
>
>
> Meanwhile, I’m looking into fixing this issue, and your test case greatly
> helps me toward finding the fix faster.
>
>
>
> I tried diagnosing the bug in EDT/SequencedEvent using heap dumps ... but
> I got no clues, very tricky.
>
>
>
> Good luck,
>
> Laurent
>
>
>
>

-- 
-- 
Laurent Bourgès

Re: OpenJdk11-28-EA JDialog hanging

[Krishna Addepalli]

Hi Laurent,

 

Sorry, I could not get to the root cause yet. Seems like it might take some 
time and some hard debugging.

 

Meanwhile, I’m attaching a simple patch file which effectively reverts the 
earlier fix that was done for JDK-8152974.

Please try this and let me know if this solves your problem. Then I’ll create a 
backout bug and push this patch.

 

Thanks,

Krishna

 

From: Laurent Bourgès  
Sent: Thursday, September 27, 2018 12:57 PM
To: Krishna Addepalli 
Cc: Phil Race ; Sergey Bylokhov 
; awt-dev@openjdk.java.net
Subject: Re:  OpenJdk11-28-EA JDialog hanging

 

Any progress on this bug, krishna ?

 

At least could you explain how SequencedEvent should be processed when multiple 
AppContexts are present ?

 

I could help but I have no clue what's going on ... I observed multiple several 
EDT, AppContexts, awt events, it is very complicated to understand such event 
handling.

 

Cheers,

Laurent

 

Le jeu. 6 sept. 2018 à 18:02, Laurent Bourgès mailto:bourges.laur...@gmail.com"bourges.laur...@gmail.com> a écrit :

Hi Krishna,

Le jeu. 6 sept. 2018 à 16:08, Krishna Addepalli mailto:krishna.addepa...@oracle.com"krishna.addepa...@oracle.com> a écrit :

Hi Laurent,

 

Thanks for providing the test case. I was able to reproduce the issue. Glad to 
know that you found a workaround, as this issue is a bit tricky to fix.

Great.

 

Meanwhile, I’m looking into fixing this issue, and your test case greatly helps 
me toward finding the fix faster.

 

I tried diagnosing the bug in EDT/SequencedEvent using heap dumps ... but I got 
no clues, very tricky.

 

Good luck,

Laurent

 


revert.patch
Description: Binary data

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Any progress on this bug, krishna ?

At least could you explain how SequencedEvent should be processed when
multiple AppContexts are present ?

I could help but I have no clue what's going on ... I observed multiple
several EDT, AppContexts, awt events, it is very complicated to understand
such event handling.

Cheers,
Laurent

Le jeu. 6 sept. 2018 à 18:02, Laurent Bourgès  a
écrit :

> Hi Krishna,
>
> Le jeu. 6 sept. 2018 à 16:08, Krishna Addepalli <
> krishna.addepa...@oracle.com> a écrit :
>
>> Hi Laurent,
>>
>> Thanks for providing the test case. I was able to reproduce the issue.
>> Glad to know that you found a workaround, as this issue is a bit tricky to
>> fix.
>>
> Great.
>
> Meanwhile, I’m looking into fixing this issue, and your test case greatly
>> helps me toward finding the fix faster.
>>
>
> I tried diagnosing the bug in EDT/SequencedEvent using heap dumps ... but
> I got no clues, very tricky.
>
> Good luck,
> Laurent
>
>

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Krishna,

Le jeu. 6 sept. 2018 à 16:08, Krishna Addepalli <
krishna.addepa...@oracle.com> a écrit :

> Hi Laurent,
>
> Thanks for providing the test case. I was able to reproduce the issue.
> Glad to know that you found a workaround, as this issue is a bit tricky to
> fix.
>
Great.

Meanwhile, I’m looking into fixing this issue, and your test case greatly
> helps me toward finding the fix faster.
>

I tried diagnosing the bug in EDT/SequencedEvent using heap dumps ... but I
got no clues, very tricky.

Good luck,
Laurent

Re: OpenJdk11-28-EA JDialog hanging

[Krishna Addepalli]

Hi Laurent,

Thanks for providing the test case. I was able to reproduce the issue. Glad to 
know that you found a workaround, as this issue is a bit tricky to fix.
Meanwhile, I’m looking into fixing this issue, and your test case greatly helps 
me toward finding the fix faster.

Krishna

> On 05-Sep-2018, at 8:29 PM, Laurent Bourgès  wrote:
> 
> Hi again,
> 
> FYI Today I managed fixing the AWT deadlock by using the forementioned 
> workaround:
> - use a specific thread pool within the Main thread group (not JNLP's 
> AppContext) to relay the EDT invocations (invokeLater / invokeAndWait) as I 
> figured out that SplashScreen & DownloadIndicator dialogs were using the JNLP 
> AppContext
> => 2 concurrent AppContexts were used and 2 event dispatcher threads led to 
> deadlocks in AWT SequencedEvent processing (Window Gain / Lost focus).
> 
> With that workaround, all EDT actions from ITW are delivered via the Main 
> AppContext and it works well now : no more AWT hanging !
> 
> Laurent
> 
> Le mer. 5 sept. 2018 à 08:45, Laurent Bourgès  > a écrit :
> Hi,
> Should we submit a new bug or complete the opened bug with this reproducer ?
> 
> It is quite critical for OpenJDK 11 adoption as I expect linux distributions 
> at least will provide icedtea-web for javaws support, even for 11+.
> 
> I will try implementing a workaround redirecting EDT using a single 
> AppContext... to reduce the opportunity to have deadlock = only 1 EDT used at 
> the same time.
> 
> Regards,
> Laurent
> 
> Le mar. 4 sept. 2018 à 22:11, Laurent Bourgès  > a écrit :
> Hi Krishna,
> 
> Thanks for your answers, I managed writing a simple reproducer, see below.
> I inspected heap dumps on jvisualvm but it looks like the First 
> SequencedEvent is not consumed and is blocking the queue for ever. 
> 
> On JDK8 or JDK10: it works (windows are animated and not hanging).
> On JDK11: it starts but is immediately frozen !
> 
> Could you have a look ?
> 
> 
> import java.awt.AWTEvent;
> import java.awt.BorderLayout;
> import java.awt.Dimension;
> import java.awt.Toolkit;
> import java.awt.event.ActionEvent;
> import java.awt.event.ActionListener;
> import java.awt.event.WindowEvent;
> import java.lang.reflect.Constructor;
> import javax.swing.JButton;
> 
> import javax.swing.JFrame;
> import javax.swing.JLabel;
> import javax.swing.SwingUtilities;
> import javax.swing.Timer;
> import sun.awt.AppContext;
> import sun.awt.SunToolkit;
> 
> /*
>  * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
>  * @author Laurent Bourges
>  */
> public class TestWinEvent extends JFrame implements ActionListener {
> 
> private static final long serialVersionUID = 1L;
> 
> private int counter = 0;
> private JButton btn;
> 
> public static void main(String[] args) {
> createWin(1);
> createWin(2);
> }
> 
> private static void createWin(int tgNum) {
> ThreadGroup tg = new ThreadGroup("TG " + tgNum);
> 
> Thread t = new Thread(tg, new Runnable() {
> public void run() {
> AppContext context = SunToolkit.createNewAppContext();
> 
> SwingUtilities.invokeLater(new Runnable() {
> public void run() {
> final TestWinEvent window = new TestWinEvent(tgNum);
> window.setVisible(true);
> 
> new Timer(10, window).start();
> }
> });
> }
> });
> t.start();
> }
> 
> public TestWinEvent(final int num) {
> super("Test Window + " + num);
> setMinimumSize(new Dimension(300, 200));
> setLocation(100 + 400 * (num - 1), 100);
> 
> setLayout(new BorderLayout());
> JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
> add(textBlock);
> 
> btn = new JButton("TEST");
> btn.addActionListener(new ActionListener() {
> @Override
> public void actionPerformed(ActionEvent e) {
> System.out.println("Button#" + num + " clicked: " + counter);
> }
> 
> });
> add(btn, BorderLayout.SOUTH);
> 
> setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> pack();
> }
> 
> @Override
> public void actionPerformed(ActionEvent e) {
> AWTEvent eventOne = 
> getSequencedEvent(WindowEvent.WINDOW_GAINED_FOCUS);
> AWTEvent eventTwo = getSequencedEvent(WindowEvent.WINDOW_LOST_FOCUS);
> 
> btn.setText("TEST " + (counter++));
> 
> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventOne);
> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventTwo);
> }
> 
> private AWTEvent getSequencedEvent(int id) {
> AWTEvent wrapMe = new WindowEvent(this, id);
> try {
> @SuppressWarnings("unchecked")
> Class se

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi again,

FYI Today I managed fixing the AWT deadlock by using the forementioned
workaround:
- use a specific thread pool within the Main thread group (not JNLP's
AppContext) to relay the EDT invocations (invokeLater / invokeAndWait) as I
figured out that SplashScreen & DownloadIndicator dialogs were using the
JNLP AppContext
=> 2 concurrent AppContexts were used and 2 event dispatcher threads led to
deadlocks in AWT SequencedEvent processing (Window Gain / Lost focus).

With that workaround, all EDT actions from ITW are delivered via the Main
AppContext and it works well now : no more AWT hanging !

Laurent

Le mer. 5 sept. 2018 à 08:45, Laurent Bourgès  a
écrit :

> Hi,
> Should we submit a new bug or complete the opened bug with this reproducer
> ?
>
> It is quite critical for OpenJDK 11 adoption as I expect linux
> distributions at least will provide icedtea-web for javaws support, even
> for 11+.
>
> I will try implementing a workaround redirecting EDT using a single
> AppContext... to reduce the opportunity to have deadlock = only 1 EDT used
> at the same time.
>
> Regards,
> Laurent
>
> Le mar. 4 sept. 2018 à 22:11, Laurent Bourgès 
> a écrit :
>
>> Hi Krishna,
>>
>> Thanks for your answers, I managed writing a simple reproducer, see below.
>> I inspected heap dumps on jvisualvm but it looks like the First
>> SequencedEvent is not consumed and is blocking the queue for ever.
>>
>> On JDK8 or JDK10: it works (windows are animated and not hanging).
>> On JDK11: it starts but is immediately frozen !
>>
>> Could you have a look ?
>>
>> 
>> import java.awt.AWTEvent;
>> import java.awt.BorderLayout;
>> import java.awt.Dimension;
>> import java.awt.Toolkit;
>> import java.awt.event.ActionEvent;
>> import java.awt.event.ActionListener;
>> import java.awt.event.WindowEvent;
>> import java.lang.reflect.Constructor;
>> import javax.swing.JButton;
>>
>> import javax.swing.JFrame;
>> import javax.swing.JLabel;
>> import javax.swing.SwingUtilities;
>> import javax.swing.Timer;
>> import sun.awt.AppContext;
>> import sun.awt.SunToolkit;
>>
>> /*
>>  * Running this code causes the AWT Event Queues to be blocked on
>> OpenJDK11
>>  * @author Laurent Bourges
>>  */
>> public class TestWinEvent extends JFrame implements ActionListener {
>>
>> private static final long serialVersionUID = 1L;
>>
>> private int counter = 0;
>> private JButton btn;
>>
>> public static void main(String[] args) {
>> createWin(1);
>> createWin(2);
>> }
>>
>> private static void createWin(int tgNum) {
>> ThreadGroup tg = new ThreadGroup("TG " + tgNum);
>>
>> Thread t = new Thread(tg, new Runnable() {
>> public void run() {
>> AppContext context = SunToolkit.createNewAppContext();
>>
>> SwingUtilities.invokeLater(new Runnable() {
>> public void run() {
>> final TestWinEvent window = new
>> TestWinEvent(tgNum);
>> window.setVisible(true);
>>
>> new Timer(10, window).start();
>> }
>> });
>> }
>> });
>> t.start();
>> }
>>
>> public TestWinEvent(final int num) {
>> super("Test Window + " + num);
>> setMinimumSize(new Dimension(300, 200));
>> setLocation(100 + 400 * (num - 1), 100);
>>
>> setLayout(new BorderLayout());
>> JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
>> add(textBlock);
>>
>> btn = new JButton("TEST");
>> btn.addActionListener(new ActionListener() {
>> @Override
>> public void actionPerformed(ActionEvent e) {
>> System.out.println("Button#" + num + " clicked: " +
>> counter);
>> }
>>
>> });
>> add(btn, BorderLayout.SOUTH);
>>
>> setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>> pack();
>> }
>>
>> @Override
>> public void actionPerformed(ActionEvent e) {
>> AWTEvent eventOne =
>> getSequencedEvent(WindowEvent.WINDOW_GAINED_FOCUS);
>> AWTEvent eventTwo =
>> getSequencedEvent(WindowEvent.WINDOW_LOST_FOCUS);
>>
>> btn.setText("TEST " + (counter++));
>>
>>
>> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventOne);
>>
>> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventTwo);
>> }
>>
>> private AWTEvent getSequencedEvent(int id) {
>> AWTEvent wrapMe = new WindowEvent(this, id);
>> try {
>> @SuppressWarnings("unchecked")
>> Class seqClass = (Class> AWTEvent>) Class.forName("java.awt.SequencedEvent");
>> Constructor seqConst =
>> seqClass.getConstructor(AWTEvent.class);
>> seqConst.setAccessible(true);
>> AWTEvent instance = seqConst.newInstance(wrapMe);
>> return instance;
>> } catch (Throwable err) {
>> throw new Error("Unable to in

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi,
Should we submit a new bug or complete the opened bug with this reproducer ?

It is quite critical for OpenJDK 11 adoption as I expect linux
distributions at least will provide icedtea-web for javaws support, even
for 11+.

I will try implementing a workaround redirecting EDT using a single
AppContext... to reduce the opportunity to have deadlock = only 1 EDT used
at the same time.

Regards,
Laurent

Le mar. 4 sept. 2018 à 22:11, Laurent Bourgès  a
écrit :

> Hi Krishna,
>
> Thanks for your answers, I managed writing a simple reproducer, see below.
> I inspected heap dumps on jvisualvm but it looks like the First
> SequencedEvent is not consumed and is blocking the queue for ever.
>
> On JDK8 or JDK10: it works (windows are animated and not hanging).
> On JDK11: it starts but is immediately frozen !
>
> Could you have a look ?
>
> 
> import java.awt.AWTEvent;
> import java.awt.BorderLayout;
> import java.awt.Dimension;
> import java.awt.Toolkit;
> import java.awt.event.ActionEvent;
> import java.awt.event.ActionListener;
> import java.awt.event.WindowEvent;
> import java.lang.reflect.Constructor;
> import javax.swing.JButton;
>
> import javax.swing.JFrame;
> import javax.swing.JLabel;
> import javax.swing.SwingUtilities;
> import javax.swing.Timer;
> import sun.awt.AppContext;
> import sun.awt.SunToolkit;
>
> /*
>  * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
>  * @author Laurent Bourges
>  */
> public class TestWinEvent extends JFrame implements ActionListener {
>
> private static final long serialVersionUID = 1L;
>
> private int counter = 0;
> private JButton btn;
>
> public static void main(String[] args) {
> createWin(1);
> createWin(2);
> }
>
> private static void createWin(int tgNum) {
> ThreadGroup tg = new ThreadGroup("TG " + tgNum);
>
> Thread t = new Thread(tg, new Runnable() {
> public void run() {
> AppContext context = SunToolkit.createNewAppContext();
>
> SwingUtilities.invokeLater(new Runnable() {
> public void run() {
> final TestWinEvent window = new
> TestWinEvent(tgNum);
> window.setVisible(true);
>
> new Timer(10, window).start();
> }
> });
> }
> });
> t.start();
> }
>
> public TestWinEvent(final int num) {
> super("Test Window + " + num);
> setMinimumSize(new Dimension(300, 200));
> setLocation(100 + 400 * (num - 1), 100);
>
> setLayout(new BorderLayout());
> JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
> add(textBlock);
>
> btn = new JButton("TEST");
> btn.addActionListener(new ActionListener() {
> @Override
> public void actionPerformed(ActionEvent e) {
> System.out.println("Button#" + num + " clicked: " +
> counter);
> }
>
> });
> add(btn, BorderLayout.SOUTH);
>
> setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> pack();
> }
>
> @Override
> public void actionPerformed(ActionEvent e) {
> AWTEvent eventOne =
> getSequencedEvent(WindowEvent.WINDOW_GAINED_FOCUS);
> AWTEvent eventTwo =
> getSequencedEvent(WindowEvent.WINDOW_LOST_FOCUS);
>
> btn.setText("TEST " + (counter++));
>
>
> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventOne);
>
> Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventTwo);
> }
>
> private AWTEvent getSequencedEvent(int id) {
> AWTEvent wrapMe = new WindowEvent(this, id);
> try {
> @SuppressWarnings("unchecked")
> Class seqClass = (Class AWTEvent>) Class.forName("java.awt.SequencedEvent");
> Constructor seqConst =
> seqClass.getConstructor(AWTEvent.class);
> seqConst.setAccessible(true);
> AWTEvent instance = seqConst.newInstance(wrapMe);
> return instance;
> } catch (Throwable err) {
> throw new Error("Unable to instantiate SequencedEvent", err);
> }
> }
> }
> --
>
> Regards,
> Laurent
>
> Le mar. 4 sept. 2018 à 15:59, Krishna Addepalli <
> krishna.addepa...@oracle.com> a écrit :
>
>> Hi Laurent,
>>
>> Thanks for bringing this up. I have fixed a problem in this area
>> JDK-8152974, which is about AWT hang when SequencedEvents arrive out of
>> order.
>> However, the fix was partial, and same problem was reported in
>> JDK8(because of webstart), after it was backported. At that point, the fix
>> was reverted in JDK8, and since we couldn’t find a scenario in JDK11 (since
>> webstart is deprecated). It would be helpful if you could provide smallest
>> possible test case / sequence of steps to reproduce the problem.
>>
>> Thanks,
>> Krishna
>>
>> > On 04-Sep-2018, at 6:26 PM, Laurent Bourgès 
>> wrote:
>> >
>> > Phi

Re: OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Hi Krishna,

Thanks for your answers, I managed writing a simple reproducer, see below.
I inspected heap dumps on jvisualvm but it looks like the First
SequencedEvent is not consumed and is blocking the queue for ever.

On JDK8 or JDK10: it works (windows are animated and not hanging).
On JDK11: it starts but is immediately frozen !

Could you have a look ?


import java.awt.AWTEvent;
import java.awt.BorderLayout;
import java.awt.Dimension;
import java.awt.Toolkit;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.awt.event.WindowEvent;
import java.lang.reflect.Constructor;
import javax.swing.JButton;

import javax.swing.JFrame;
import javax.swing.JLabel;
import javax.swing.SwingUtilities;
import javax.swing.Timer;
import sun.awt.AppContext;
import sun.awt.SunToolkit;

/*
 * Running this code causes the AWT Event Queues to be blocked on OpenJDK11
 * @author Laurent Bourges
 */
public class TestWinEvent extends JFrame implements ActionListener {

private static final long serialVersionUID = 1L;

private int counter = 0;
private JButton btn;

public static void main(String[] args) {
createWin(1);
createWin(2);
}

private static void createWin(int tgNum) {
ThreadGroup tg = new ThreadGroup("TG " + tgNum);

Thread t = new Thread(tg, new Runnable() {
public void run() {
AppContext context = SunToolkit.createNewAppContext();

SwingUtilities.invokeLater(new Runnable() {
public void run() {
final TestWinEvent window = new TestWinEvent(tgNum);
window.setVisible(true);

new Timer(10, window).start();
}
});
}
});
t.start();
}

public TestWinEvent(final int num) {
super("Test Window + " + num);
setMinimumSize(new Dimension(300, 200));
setLocation(100 + 400 * (num - 1), 100);

setLayout(new BorderLayout());
JLabel textBlock = new JLabel("Lorem ipsum dolor sit amet...");
add(textBlock);

btn = new JButton("TEST");
btn.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
System.out.println("Button#" + num + " clicked: " +
counter);
}

});
add(btn, BorderLayout.SOUTH);

setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
pack();
}

@Override
public void actionPerformed(ActionEvent e) {
AWTEvent eventOne =
getSequencedEvent(WindowEvent.WINDOW_GAINED_FOCUS);
AWTEvent eventTwo =
getSequencedEvent(WindowEvent.WINDOW_LOST_FOCUS);

btn.setText("TEST " + (counter++));


Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventOne);

Toolkit.getDefaultToolkit().getSystemEventQueue().postEvent(eventTwo);
}

private AWTEvent getSequencedEvent(int id) {
AWTEvent wrapMe = new WindowEvent(this, id);
try {
@SuppressWarnings("unchecked")
Class seqClass = (Class) Class.forName("java.awt.SequencedEvent");
Constructor seqConst =
seqClass.getConstructor(AWTEvent.class);
seqConst.setAccessible(true);
AWTEvent instance = seqConst.newInstance(wrapMe);
return instance;
} catch (Throwable err) {
throw new Error("Unable to instantiate SequencedEvent", err);
}
}
}
--

Regards,
Laurent

Le mar. 4 sept. 2018 à 15:59, Krishna Addepalli <
krishna.addepa...@oracle.com> a écrit :

> Hi Laurent,
>
> Thanks for bringing this up. I have fixed a problem in this area
> JDK-8152974, which is about AWT hang when SequencedEvents arrive out of
> order.
> However, the fix was partial, and same problem was reported in
> JDK8(because of webstart), after it was backported. At that point, the fix
> was reverted in JDK8, and since we couldn’t find a scenario in JDK11 (since
> webstart is deprecated). It would be helpful if you could provide smallest
> possible test case / sequence of steps to reproduce the problem.
>
> Thanks,
> Krishna
>
> > On 04-Sep-2018, at 6:26 PM, Laurent Bourgès 
> wrote:
> >
> > Phil & Sergey,
> >
> > I am testing IcedTea-Web 1.7 with OpenJDK11-28 and experienced many
> > times the GUI hanging with AWT-EventQueue threads in the WAITING state
> > (SequencedEvent) at EventQueue.getNextEvent().
> >
> > I fixed the netx code (EDT violations in swing code) but the problem
> > is still happening randomly. This JavaWS implementation displays
> > several JDialogs: Splash screen + download dialogs + Security prompts.
> > When the application is hanging, I can not click on the Proceed/Cancel
> > buttons of the Security dialogs and it is blocked forever.
> >
> > Are you aware about this problem ?
> >
> > As I can reproduce the problem, I can provide a heap-dump if you need.
> >
> > Here is a complete t

Re: OpenJdk11-28-EA JDialog hanging

[Krishna Addepalli]

Hi Laurent,

Thanks for bringing this up. I have fixed a problem in this area JDK-8152974, 
which is about AWT hang when SequencedEvents arrive out of order.
However, the fix was partial, and same problem was reported in JDK8(because of 
webstart), after it was backported. At that point, the fix was reverted in 
JDK8, and since we couldn’t find a scenario in JDK11 (since webstart is 
deprecated). It would be helpful if you could provide smallest possible test 
case / sequence of steps to reproduce the problem.

Thanks,
Krishna

> On 04-Sep-2018, at 6:26 PM, Laurent Bourgès  wrote:
> 
> Phil & Sergey,
> 
> I am testing IcedTea-Web 1.7 with OpenJDK11-28 and experienced many
> times the GUI hanging with AWT-EventQueue threads in the WAITING state
> (SequencedEvent) at EventQueue.getNextEvent().
> 
> I fixed the netx code (EDT violations in swing code) but the problem
> is still happening randomly. This JavaWS implementation displays
> several JDialogs: Splash screen + download dialogs + Security prompts.
> When the application is hanging, I can not click on the Proceed/Cancel
> buttons of the Security dialogs and it is blocked forever.
> 
> Are you aware about this problem ?
> 
> As I can reproduce the problem, I can provide a heap-dump if you need.
> 
> Here is a complete thread dump:
> 
> Full thread dump OpenJDK 64-Bit Server VM (11+28 mixed mode):
> 
> Threads class SMR info:
> _java_thread_list=0x7f94500170a0, length=44, elements={
> 0x7f94b0013800, 0x7f94b01a3800, 0x7f94b01a7800, 
> 0x7f94b01ba800,
> 0x7f94b01bc800, 0x7f94b01be800, 0x7f94b01c0800, 
> 0x7f94b01ff800,
> 0x7f94b02d8800, 0x7f94b0462000, 0x7f94b0467800, 
> 0x7f94b046b000,
> 0x7f94b04d7800, 0x7f9434004000, 0x7f943400e000, 
> 0x7f94b0aa8800,
> 0x7f94b0b2b000, 0x7f94b0b43800, 0x7f942c075000, 
> 0x7f9428017800,
> 0x7f9428024000, 0x7f942c078000, 0x7f942c15b000, 
> 0x7f942c1d,
> 0x7f942c1ce800, 0x7f942c195800, 0x7f942c191000, 
> 0x7f942c192000,
> 0x7f942c193000, 0x7f942c1c7800, 0x7f942c1c9000, 
> 0x7f942c1ca800,
> 0x7f942c1cc800, 0x7f942c166800, 0x7f942c168000, 
> 0x7f942c16a000,
> 0x7f942c16c000, 0x7f942c16d800, 0x7f942c16e800, 
> 0x7f942c16f800,
> 0x7f942c170800, 0x7f942c1d8000, 0x7f942c1d2000, 0x7f942c1d3800
> }
> 
> "main" #1 prio=5 os_prio=0 cpu=728,96ms elapsed=28,25s
> tid=0x7f94b0013800 nid=0x15e1 in Object.wait()
> [0x7f94b9bee000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(java.base@11/Native Method)
>- waiting on <0xcd9c0c78> (a 
> net.sourceforge.jnlp.Launcher$TgThread)
>at java.lang.Thread.join(java.base@11/Thread.java:1305)
>- waiting to re-lock in wait() <0xcd9c0c78> (a
> net.sourceforge.jnlp.Launcher$TgThread)
>at java.lang.Thread.join(java.base@11/Thread.java:1379)
>at net.sourceforge.jnlp.Launcher.launch(java.desktop@11/Launcher.java:258)
>at net.sourceforge.jnlp.Launcher.launch(java.desktop@11/Launcher.java:208)
>at net.sourceforge.jnlp.Launcher.launch(java.desktop@11/Launcher.java:287)
>at 
> net.sourceforge.jnlp.runtime.JnlpBoot.run(java.desktop@11/JnlpBoot.java:67)
>at net.sourceforge.jnlp.runtime.Boot.run(java.desktop@11/Boot.java:270)
>at net.sourceforge.jnlp.runtime.Boot.run(java.desktop@11/Boot.java:65)
>at java.security.AccessController.doPrivileged(java.base@11/Native Method)
>at net.sourceforge.jnlp.runtime.Boot.main(java.desktop@11/Boot.java:210)
> 
> "Reference Handler" #2 daemon prio=10 os_prio=0 cpu=2,57ms
> elapsed=28,24s tid=0x7f94b01a3800 nid=0x15e8 waiting on condition
> [0x7f9490efc000]
>   java.lang.Thread.State: RUNNABLE
>at java.lang.ref.Reference.waitForReferencePendingList(java.base@11/Native
> Method)
>at 
> java.lang.ref.Reference.processPendingReferences(java.base@11/Reference.java:241)
>at 
> java.lang.ref.Reference$ReferenceHandler.run(java.base@11/Reference.java:213)
> 
> "Finalizer" #3 daemon prio=8 os_prio=0 cpu=0,70ms elapsed=28,24s
> tid=0x7f94b01a7800 nid=0x15e9 in Object.wait()
> [0x7f9490dfb000]
>   java.lang.Thread.State: WAITING (on object monitor)
>at java.lang.Object.wait(java.base@11/Native Method)
>- waiting on <0xc01f16d0> (a java.lang.ref.ReferenceQueue$Lock)
>at 
> java.lang.ref.ReferenceQueue.remove(java.base@11/ReferenceQueue.java:155)
>- waiting to re-lock in wait() <0xc01f16d0> (a
> java.lang.ref.ReferenceQueue$Lock)
>at 
> java.lang.ref.ReferenceQueue.remove(java.base@11/ReferenceQueue.java:176)
>at 
> java.lang.ref.Finalizer$FinalizerThread.run(java.base@11/Finalizer.java:170)
> 
> "Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0,29ms
> elapsed=28,23s tid=0x7f94b01ba800 nid=0x15ea waiting on condition
> [0x]
>   java.lang.Thread.State: RUNNABLE
> 
> "C2 CompilerThread0" #5 daemon prio=9 os_prio

OpenJdk11-28-EA JDialog hanging

[Laurent Bourgès]

Phil & Sergey,

I am testing IcedTea-Web 1.7 with OpenJDK11-28 and experienced many
times the GUI hanging with AWT-EventQueue threads in the WAITING state
(SequencedEvent) at EventQueue.getNextEvent().

I fixed the netx code (EDT violations in swing code) but the problem
is still happening randomly. This JavaWS implementation displays
several JDialogs: Splash screen + download dialogs + Security prompts.
When the application is hanging, I can not click on the Proceed/Cancel
buttons of the Security dialogs and it is blocked forever.

Are you aware about this problem ?

As I can reproduce the problem, I can provide a heap-dump if you need.

Here is a complete thread dump:

Full thread dump OpenJDK 64-Bit Server VM (11+28 mixed mode):

Threads class SMR info:
_java_thread_list=0x7f94500170a0, length=44, elements={
0x7f94b0013800, 0x7f94b01a3800, 0x7f94b01a7800, 0x7f94b01ba800,
0x7f94b01bc800, 0x7f94b01be800, 0x7f94b01c0800, 0x7f94b01ff800,
0x7f94b02d8800, 0x7f94b0462000, 0x7f94b0467800, 0x7f94b046b000,
0x7f94b04d7800, 0x7f9434004000, 0x7f943400e000, 0x7f94b0aa8800,
0x7f94b0b2b000, 0x7f94b0b43800, 0x7f942c075000, 0x7f9428017800,
0x7f9428024000, 0x7f942c078000, 0x7f942c15b000, 0x7f942c1d,
0x7f942c1ce800, 0x7f942c195800, 0x7f942c191000, 0x7f942c192000,
0x7f942c193000, 0x7f942c1c7800, 0x7f942c1c9000, 0x7f942c1ca800,
0x7f942c1cc800, 0x7f942c166800, 0x7f942c168000, 0x7f942c16a000,
0x7f942c16c000, 0x7f942c16d800, 0x7f942c16e800, 0x7f942c16f800,
0x7f942c170800, 0x7f942c1d8000, 0x7f942c1d2000, 0x7f942c1d3800
}

"main" #1 prio=5 os_prio=0 cpu=728,96ms elapsed=28,25s
tid=0x7f94b0013800 nid=0x15e1 in Object.wait()
[0x7f94b9bee000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(java.base@11/Native Method)
- waiting on <0xcd9c0c78> (a net.sourceforge.jnlp.Launcher$TgThread)
at java.lang.Thread.join(java.base@11/Thread.java:1305)
- waiting to re-lock in wait() <0xcd9c0c78> (a
net.sourceforge.jnlp.Launcher$TgThread)
at java.lang.Thread.join(java.base@11/Thread.java:1379)
at net.sourceforge.jnlp.Launcher.launch(java.desktop@11/Launcher.java:258)
at net.sourceforge.jnlp.Launcher.launch(java.desktop@11/Launcher.java:208)
at net.sourceforge.jnlp.Launcher.launch(java.desktop@11/Launcher.java:287)
at 
net.sourceforge.jnlp.runtime.JnlpBoot.run(java.desktop@11/JnlpBoot.java:67)
at net.sourceforge.jnlp.runtime.Boot.run(java.desktop@11/Boot.java:270)
at net.sourceforge.jnlp.runtime.Boot.run(java.desktop@11/Boot.java:65)
at java.security.AccessController.doPrivileged(java.base@11/Native Method)
at net.sourceforge.jnlp.runtime.Boot.main(java.desktop@11/Boot.java:210)

"Reference Handler" #2 daemon prio=10 os_prio=0 cpu=2,57ms
elapsed=28,24s tid=0x7f94b01a3800 nid=0x15e8 waiting on condition
[0x7f9490efc000]
   java.lang.Thread.State: RUNNABLE
at java.lang.ref.Reference.waitForReferencePendingList(java.base@11/Native
Method)
at 
java.lang.ref.Reference.processPendingReferences(java.base@11/Reference.java:241)
at 
java.lang.ref.Reference$ReferenceHandler.run(java.base@11/Reference.java:213)

"Finalizer" #3 daemon prio=8 os_prio=0 cpu=0,70ms elapsed=28,24s
tid=0x7f94b01a7800 nid=0x15e9 in Object.wait()
[0x7f9490dfb000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(java.base@11/Native Method)
- waiting on <0xc01f16d0> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(java.base@11/ReferenceQueue.java:155)
- waiting to re-lock in wait() <0xc01f16d0> (a
java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(java.base@11/ReferenceQueue.java:176)
at 
java.lang.ref.Finalizer$FinalizerThread.run(java.base@11/Finalizer.java:170)

"Signal Dispatcher" #4 daemon prio=9 os_prio=0 cpu=0,29ms
elapsed=28,23s tid=0x7f94b01ba800 nid=0x15ea waiting on condition
[0x]
   java.lang.Thread.State: RUNNABLE

"C2 CompilerThread0" #5 daemon prio=9 os_prio=0 cpu=2917,46ms
elapsed=28,23s tid=0x7f94b01bc800 nid=0x15eb waiting on condition
[0x]
   java.lang.Thread.State: RUNNABLE
   No compile task

"C1 CompilerThread0" #7 daemon prio=9 os_prio=0 cpu=1338,81ms
elapsed=28,23s tid=0x7f94b01be800 nid=0x15ec waiting on condition
[0x]
   java.lang.Thread.State: RUNNABLE
   No compile task

"Sweeper thread" #8 daemon prio=9 os_prio=0 cpu=35,43ms elapsed=28,23s
tid=0x7f94b01c0800 nid=0x15ed runnable  [0x]
   java.lang.Thread.State: RUNNABLE

"Common-Cleaner" #9 daemon prio=8 os_prio=0 cpu=0,66ms elapsed=28,21s
tid=0x7f94b01ff800 nid=0x15ee in Object.wait()
[0x7f94904e3000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.w