JDK-8025588 : [macosx] Frozen AppKit thread in 7u40
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u40,8
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2013-09-27
  • Updated: 2017-05-17
  • Resolved: 2013-10-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u55Fixed 8 b115Fixed
Description
NetBeans user is repeatedly encountering frozen application with the following symptom.

"AppKit Thread" daemon prio=5 tid=0x00007f840a8e2800 nid=0x707 runnable [0x00007fff6eed2000]
   java.lang.Thread.State: RUNNABLE
	at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(Native Method)
	at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:549)
	at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:489)
	at sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:75)
	at sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:521)

See also the attached dump.

The user claims he never sees the problem with 7u25.

Related NetBeans bug:
https://netbeans.org/bugzilla/show_bug.cgi?id=236101
Comments
We can take it in 7u55. Please, push the fix into 7u-cpu.
24-11-2013
what about to take into 7u55 (CPU14_02)?
22-11-2013
SQE OK to take the fix into 7u60. SQE do not whant to take the fix into 7u51 (CPU14_01).
22-11-2013
Verified with JDK8b116 The problem seems to be solved
20-11-2013
We are getting more and more duplicates from NetBeans users who are using 7u40 or 7u45 on Mac. The number of users encountering the problem will be further increasing. The only answer we have for the users on Mac is to stay on 7u25 for now. Into which 7uX will the fix be backported? Thanks.
23-10-2013
It's hard to create a regression test as the issue is reproducible only in netbeans and there's no reliable way to reproduce it.
10-10-2013
Hard to reproduce in test environment.
08-10-2013
Thanks for the comments. Makes sense to me.
01-10-2013
Regarding the CCC: 1. You can't do that for 7uX. It's a public API change. But we need get it fixed in a 7 update release. 2. What do you mean under "this mechanism is not always convenient"? I don't see how calling a runnable is any different from a notifyAll() based approach (which, btw, is a pattern in java.) Please clarify this.
01-10-2013
http://ccc.us.oracle.com/8025588
01-10-2013
1. The backport to the 7uX would be different. We will hide this API and access it using an AWTAccessor. 2. When using a notifier we must wait for event dispatching using an Object.wait() method. However in case of this issue we are using a nested event loop for waiting. The runnable would also be convenient if we want to use some different synchroniser instead of a simple wait/notify approach. I've updated the CCC with this info.
01-10-2013
Petr, I have set priority to P1. Already two NetBeans users on Mac with 7u40 have filed the problem in the past few days and those users are encountering the problem repeatedly. This regression will have impact on many more users as 7u40 is used by more of them. Good you know the root cause now. NetBeans team requests the bugfix to be backported to the nearest 7uX update. The release 7u45 is the one we'd like to have this fix in. Thanks.
30-09-2013
The problem is cause by EventQueue.removeSourceEvents. It is removing the invokationEvent posted in LWCToolkit, so we never exit the nested event loop.
30-09-2013
Attaching logs from another user who reported the problem (see his original netbeans report at https://netbeans.org/bugzilla/show_bug.cgi?id=236361)
30-09-2013