[jira] [Comment Edited] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later
[
https://issues.apache.org/jira/browse/NETBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462242#comment-16462242
]
Geertjan Wielenga edited comment on NETBEANS-373 at 5/3/18 10:13 AM:
-
Synchronization flags removed via the above PR and so we should close this
blocker as fixed and resolved?
was (Author: geertjanwielenga):
Synchronization flags removed via the above PR and so we should close this
blocer as fixed and resolved?
> Netbeans sometimes freezes when showing any refactor dialog when running with
> jdk 1.8.0_152-b16 or later
>
>
> Key: NETBEANS-373
> URL: https://issues.apache.org/jira/browse/NETBEANS-373
> Project: NetBeans
> Issue Type: Bug
> Components: java - Refactoring
>Affects Versions: 8.2, 9.0
> Environment: Mac
>Reporter: Austin Stephens
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 9.0
>
> Attachments: Screen Shot 2018-04-02 at 11.22.11 AM.png, Screen Shot
> 2018-04-02 at 11.23.15 AM.png, nbpresenter.diff
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Sometimes (or almost always), when you try to do some refactor action,
> NetBeans freezes. It appears that a lock is obtained on a panel when the
> dialog is shown, and the AppKit Thread tries to get the lock while trying to
> add an accessible listener to it.
> AppKit Thread:
> {code:java}
> Container.addContainerListener:2142
> Container$AccessibleAWTContainer.addPropertyChangeListener:3885
> JComponent$AccessibleJComponent.addPropertyChangeListener:3765
> Hidden Source Calls
> CAccessible.addNotificationListeners:102
> CAccessible.:84
> CAccessible.getCAccessible:60
> {code}
> EDT Thread:
> {code:java}
> Hidden Source Calls
> Unsafe.park
> LockSupport.park:194
> AbstractQueuedSynchronizer$ConditionObject.await:2062
> EventQueue.getNextEvent:557
> EventDispatchThread.pumpOneEventForFilters:173
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForFilter:117
> WaitDispatchSupport$2.run:190
> WaitDispatchSupport$4.run:235
> WaitDispatchSupport$4.run:233
> AccessController.doPrivileged
> WaitDispatchSupport.enter:233
> Dialog.show:1070
> NbPresenter.superShow:1060
> NbPresenter.doShow:1110
> NbPresenter.run:1082
> NbPresenter.run:105
> NbMutexEventProvider$Event.doEventAccess:115
> NbMutexEventProvider$Event.readAccess:75
> LazyMutexImplementation.readAccess:71
> Mutex.readAccess:193
> NbPresenter.show:1067
> Component.show:1669
> Component.setVisible:1616
> Window.setVisible:1017
> Dialog.setVisible:1005
> ParametersPanel.showDialog:674
> RefactoringPanel.refresh:660
> RefactoringPanel.:144
> UI.openRefactoringUI:61
> ContextAnalyzer$4.show:648
> ContextAnalyzer$TextComponentTask.run:369
> RefactoringActionsProvider.doFindUsages:232
> ActionsImplementationFactory.doFindUsages:91
> WhereUsedAction.performAction:52
> RefactoringGlobalAction$ContextAction.actionPerformed:172
> TopComponent.processKeyBinding:1151
> JComponent.processKeyBindings:2963
> JComponent.processKeyEvent:2863
> Component.processEvent:6355
> Container.processEvent:2259
> Component.dispatchEventImpl:4961
> Container.dispatchEventImpl:2317
> Component.dispatchEvent:4793
> KeyboardFocusManager.redispatchEvent:1955
> DefaultKeyboardFocusManager.dispatchKeyEvent:827
> DefaultKeyboardFocusManager.preDispatchKeyEvent:1096
> DefaultKeyboardFocusManager.typeAheadAssertions:966
> DefaultKeyboardFocusManager.dispatchEvent:792
> Component.dispatchEventImpl:4842
> Container.dispatchEventImpl:2317
> Window.dispatchEventImpl:2758
> Component.dispatchEvent:4793
> EventQueue.dispatchEventImpl:766
> EventQueue.access$500:97
> EventQueue$3.run:717
> EventQueue$3.run:711
> AccessController.doPrivileged
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:99
> EventQueue$4.run:739
> EventQueue$4.run:737
> AccessController.doPrivileged
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89
> EventQueue.dispatchEvent:736
> TimableEventQueue.dispatchEvent:136
> EventDispatchThread.pumpOneEventForFilters:199
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForHierarchy:113
> EventDispatchThread.pumpEvents:109
> EventDispatchThread.pumpEvents:101
> EventDispatchThread.run:90
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later
[
https://issues.apache.org/jira/browse/NETBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459629#comment-16459629
]
Geertjan Wielenga edited comment on NETBEANS-373 at 5/1/18 11:38 AM:
-
I think [~timboudreau] has the most recent analysis of the way forward here:
{quote}The bug is really in the JDK. Here we just need to find an effective
workaround. In this case, replanning the listener add to the event thread will
do the job - we just need to verify what the actual code path and target
component that's triggering the deadlock is.
Most likely it is the accessible component created by the dialog, simply
because there is a decent chance of another thread getting hold of the dialog
thanks to the native peer being assigned when pack() is called.{quote}
Also, [~jlahoda] comment:
{quote}My suggestion would be to delete the synchronized flag from the
showDialog method; and also delete the "synchronized (this)" from
cancelActionPerformed.{quote}
So where exactly in github.com/apache/incubator-netbeans is the file that needs
to be fixed as outlined above?
was (Author: geertjanwielenga):
I think [~timboudreau] has the most recent analysis of the way forward here:
{quote}The bug is really in the JDK. Here we just need to find an effective
workaround. In this case, replanning the listener add to the event thread will
do the job - we just need to verify what the actual code path and target
component that's triggering the deadlock is.
Most likely it is the accessible component created by the dialog, simply
because there is a decent chance of another thread getting hold of the dialog
thanks to the native peer being assigned when pack() is called.{quote}
Also, [~jlahoda] comment:
{quote}My suggestion would be to delete the synchronized flag from the
showDialog method; and also delete the "synchronized (this)" from
cancelActionPerformed.{quote}
> Netbeans sometimes freezes when showing any refactor dialog when running with
> jdk 1.8.0_152-b16 or later
>
>
> Key: NETBEANS-373
> URL: https://issues.apache.org/jira/browse/NETBEANS-373
> Project: NetBeans
> Issue Type: Bug
> Components: java - Refactoring
>Affects Versions: 8.2, 9.0
> Environment: Mac
>Reporter: Austin Stephens
>Priority: Blocker
> Fix For: 9.0
>
> Attachments: Screen Shot 2018-04-02 at 11.22.11 AM.png, Screen Shot
> 2018-04-02 at 11.23.15 AM.png, nbpresenter.diff
>
>
> Sometimes (or almost always), when you try to do some refactor action,
> NetBeans freezes. It appears that a lock is obtained on a panel when the
> dialog is shown, and the AppKit Thread tries to get the lock while trying to
> add an accessible listener to it.
> AppKit Thread:
> {code:java}
> Container.addContainerListener:2142
> Container$AccessibleAWTContainer.addPropertyChangeListener:3885
> JComponent$AccessibleJComponent.addPropertyChangeListener:3765
> Hidden Source Calls
> CAccessible.addNotificationListeners:102
> CAccessible.:84
> CAccessible.getCAccessible:60
> {code}
> EDT Thread:
> {code:java}
> Hidden Source Calls
> Unsafe.park
> LockSupport.park:194
> AbstractQueuedSynchronizer$ConditionObject.await:2062
> EventQueue.getNextEvent:557
> EventDispatchThread.pumpOneEventForFilters:173
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForFilter:117
> WaitDispatchSupport$2.run:190
> WaitDispatchSupport$4.run:235
> WaitDispatchSupport$4.run:233
> AccessController.doPrivileged
> WaitDispatchSupport.enter:233
> Dialog.show:1070
> NbPresenter.superShow:1060
> NbPresenter.doShow:1110
> NbPresenter.run:1082
> NbPresenter.run:105
> NbMutexEventProvider$Event.doEventAccess:115
> NbMutexEventProvider$Event.readAccess:75
> LazyMutexImplementation.readAccess:71
> Mutex.readAccess:193
> NbPresenter.show:1067
> Component.show:1669
> Component.setVisible:1616
> Window.setVisible:1017
> Dialog.setVisible:1005
> ParametersPanel.showDialog:674
> RefactoringPanel.refresh:660
> RefactoringPanel.:144
> UI.openRefactoringUI:61
> ContextAnalyzer$4.show:648
> ContextAnalyzer$TextComponentTask.run:369
> RefactoringActionsProvider.doFindUsages:232
> ActionsImplementationFactory.doFindUsages:91
> WhereUsedAction.performAction:52
> RefactoringGlobalAction$ContextAction.actionPerformed:172
> TopComponent.processKeyBinding:1151
> JComponent.processKeyBindings:2963
> JComponent.processKeyEvent:2863
> Component.processEvent:6355
> Container.processEvent:2259
> Component.dispatchEventImpl:4961
> Container.dispatchEventImpl:2317
>
[jira] [Comment Edited] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later
[
https://issues.apache.org/jira/browse/NETBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459629#comment-16459629
]
Geertjan Wielenga edited comment on NETBEANS-373 at 5/1/18 11:37 AM:
-
I think [~timboudreau] has the most recent analysis of the way forward here:
{quote}The bug is really in the JDK. Here we just need to find an effective
workaround. In this case, replanning the listener add to the event thread will
do the job - we just need to verify what the actual code path and target
component that's triggering the deadlock is.
Most likely it is the accessible component created by the dialog, simply
because there is a decent chance of another thread getting hold of the dialog
thanks to the native peer being assigned when pack() is called.{quote}
Also, [~jlahoda] comment:
{quote}My suggestion would be to delete the synchronized flag from the
showDialog method; and also delete the "synchronized (this)" from
cancelActionPerformed.{quote}
was (Author: geertjanwielenga):
I think [~timboudreau] has the most recent analysis of the way forward here:
{quote}The bug is really in the JDK. Here we just need to find an effective
workaround. In this case, replanning the listener add to the event thread will
do the job - we just need to verify what the actual code path and target
component that's triggering the deadlock is.
Most likely it is the accessible component created by the dialog, simply
because there is a decent chance of another thread getting hold of the dialog
thanks to the native peer being assigned when pack() is called.{quote}
> Netbeans sometimes freezes when showing any refactor dialog when running with
> jdk 1.8.0_152-b16 or later
>
>
> Key: NETBEANS-373
> URL: https://issues.apache.org/jira/browse/NETBEANS-373
> Project: NetBeans
> Issue Type: Bug
> Components: java - Refactoring
>Affects Versions: 8.2, 9.0
> Environment: Mac
>Reporter: Austin Stephens
>Priority: Blocker
> Fix For: 9.0
>
> Attachments: Screen Shot 2018-04-02 at 11.22.11 AM.png, Screen Shot
> 2018-04-02 at 11.23.15 AM.png, nbpresenter.diff
>
>
> Sometimes (or almost always), when you try to do some refactor action,
> NetBeans freezes. It appears that a lock is obtained on a panel when the
> dialog is shown, and the AppKit Thread tries to get the lock while trying to
> add an accessible listener to it.
> AppKit Thread:
> {code:java}
> Container.addContainerListener:2142
> Container$AccessibleAWTContainer.addPropertyChangeListener:3885
> JComponent$AccessibleJComponent.addPropertyChangeListener:3765
> Hidden Source Calls
> CAccessible.addNotificationListeners:102
> CAccessible.:84
> CAccessible.getCAccessible:60
> {code}
> EDT Thread:
> {code:java}
> Hidden Source Calls
> Unsafe.park
> LockSupport.park:194
> AbstractQueuedSynchronizer$ConditionObject.await:2062
> EventQueue.getNextEvent:557
> EventDispatchThread.pumpOneEventForFilters:173
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForFilter:117
> WaitDispatchSupport$2.run:190
> WaitDispatchSupport$4.run:235
> WaitDispatchSupport$4.run:233
> AccessController.doPrivileged
> WaitDispatchSupport.enter:233
> Dialog.show:1070
> NbPresenter.superShow:1060
> NbPresenter.doShow:1110
> NbPresenter.run:1082
> NbPresenter.run:105
> NbMutexEventProvider$Event.doEventAccess:115
> NbMutexEventProvider$Event.readAccess:75
> LazyMutexImplementation.readAccess:71
> Mutex.readAccess:193
> NbPresenter.show:1067
> Component.show:1669
> Component.setVisible:1616
> Window.setVisible:1017
> Dialog.setVisible:1005
> ParametersPanel.showDialog:674
> RefactoringPanel.refresh:660
> RefactoringPanel.:144
> UI.openRefactoringUI:61
> ContextAnalyzer$4.show:648
> ContextAnalyzer$TextComponentTask.run:369
> RefactoringActionsProvider.doFindUsages:232
> ActionsImplementationFactory.doFindUsages:91
> WhereUsedAction.performAction:52
> RefactoringGlobalAction$ContextAction.actionPerformed:172
> TopComponent.processKeyBinding:1151
> JComponent.processKeyBindings:2963
> JComponent.processKeyEvent:2863
> Component.processEvent:6355
> Container.processEvent:2259
> Component.dispatchEventImpl:4961
> Container.dispatchEventImpl:2317
> Component.dispatchEvent:4793
> KeyboardFocusManager.redispatchEvent:1955
> DefaultKeyboardFocusManager.dispatchKeyEvent:827
> DefaultKeyboardFocusManager.preDispatchKeyEvent:1096
> DefaultKeyboardFocusManager.typeAheadAssertions:966
> DefaultKeyboardFocusManager.dispatchEvent:792
>
[jira] [Comment Edited] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later
[
https://issues.apache.org/jira/browse/NETBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447738#comment-16447738
]
Thomas Corte edited comment on NETBEANS-373 at 4/23/18 8:26 AM:
Not sure why, but this issue seems to have gotten worse with the latest macOS
update. Previously, I was able to circumvent the freezing most of the time by
using only the keyboard (instead of the mouse) to use the refactor dialog. Now
even that makes NetBeans freeze almost 100% of the time. This practically
renders NetBeans *unusable* on macOS.
NetBeans IDE 8.2 (Build 201609300101), Patch 2
Java 1.8.0_162
Mac OS X Version 10.13.4
Note that, as opposed to what was claimed in older tickets, the problems does
*not* go away with different look settings.
was (Author: thomas.corte):
Not sure why, but this issue seems to have gotten worse with the latest macOS
update. Previously, I was able to circumvent the freezing most of the time by
using only the keyboard (instead of the mouse) to use the refactor dialog. Now
even that makes NetBeans freeze almost 100% of the time. This practically
renders NetBeans *unusable* on macOS.
NetBeans IDE 8.2 (Build 201609300101), Patch 2
Java 1.8.0_162
Mac OS X Version 10.13.4
Note that, as opposed to what was claimed in older tickets, the problems does
*not* go away with different lool settings.
> Netbeans sometimes freezes when showing any refactor dialog when running with
> jdk 1.8.0_152-b16 or later
>
>
> Key: NETBEANS-373
> URL: https://issues.apache.org/jira/browse/NETBEANS-373
> Project: NetBeans
> Issue Type: Bug
> Components: java - Refactoring
>Affects Versions: 8.2, 9.0
> Environment: Mac
>Reporter: Austin Stephens
>Assignee: Thomas Corte
>Priority: Blocker
> Attachments: Screen Shot 2018-04-02 at 11.22.11 AM.png, Screen Shot
> 2018-04-02 at 11.23.15 AM.png, nbpresenter.diff
>
>
> Sometimes (or almost always), when you try to do some refactor action,
> NetBeans freezes. It appears that a lock is obtained on a panel when the
> dialog is shown, and the AppKit Thread tries to get the lock while trying to
> add an accessible listener to it.
> AppKit Thread:
> {code:java}
> Container.addContainerListener:2142
> Container$AccessibleAWTContainer.addPropertyChangeListener:3885
> JComponent$AccessibleJComponent.addPropertyChangeListener:3765
> Hidden Source Calls
> CAccessible.addNotificationListeners:102
> CAccessible.:84
> CAccessible.getCAccessible:60
> {code}
> EDT Thread:
> {code:java}
> Hidden Source Calls
> Unsafe.park
> LockSupport.park:194
> AbstractQueuedSynchronizer$ConditionObject.await:2062
> EventQueue.getNextEvent:557
> EventDispatchThread.pumpOneEventForFilters:173
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForFilter:117
> WaitDispatchSupport$2.run:190
> WaitDispatchSupport$4.run:235
> WaitDispatchSupport$4.run:233
> AccessController.doPrivileged
> WaitDispatchSupport.enter:233
> Dialog.show:1070
> NbPresenter.superShow:1060
> NbPresenter.doShow:1110
> NbPresenter.run:1082
> NbPresenter.run:105
> NbMutexEventProvider$Event.doEventAccess:115
> NbMutexEventProvider$Event.readAccess:75
> LazyMutexImplementation.readAccess:71
> Mutex.readAccess:193
> NbPresenter.show:1067
> Component.show:1669
> Component.setVisible:1616
> Window.setVisible:1017
> Dialog.setVisible:1005
> ParametersPanel.showDialog:674
> RefactoringPanel.refresh:660
> RefactoringPanel.:144
> UI.openRefactoringUI:61
> ContextAnalyzer$4.show:648
> ContextAnalyzer$TextComponentTask.run:369
> RefactoringActionsProvider.doFindUsages:232
> ActionsImplementationFactory.doFindUsages:91
> WhereUsedAction.performAction:52
> RefactoringGlobalAction$ContextAction.actionPerformed:172
> TopComponent.processKeyBinding:1151
> JComponent.processKeyBindings:2963
> JComponent.processKeyEvent:2863
> Component.processEvent:6355
> Container.processEvent:2259
> Component.dispatchEventImpl:4961
> Container.dispatchEventImpl:2317
> Component.dispatchEvent:4793
> KeyboardFocusManager.redispatchEvent:1955
> DefaultKeyboardFocusManager.dispatchKeyEvent:827
> DefaultKeyboardFocusManager.preDispatchKeyEvent:1096
> DefaultKeyboardFocusManager.typeAheadAssertions:966
> DefaultKeyboardFocusManager.dispatchEvent:792
> Component.dispatchEventImpl:4842
> Container.dispatchEventImpl:2317
> Window.dispatchEventImpl:2758
> Component.dispatchEvent:4793
> EventQueue.dispatchEventImpl:766
> EventQueue.access$500:97
>
[jira] [Comment Edited] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later
[
https://issues.apache.org/jira/browse/NETBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16447738#comment-16447738
]
Thomas Corte edited comment on NETBEANS-373 at 4/23/18 8:25 AM:
Not sure why, but this issue seems to have gotten worse with the latest macOS
update. Previously, I was able to circumvent the freezing most of the time by
using only the keyboard (instead of the mouse) to use the refactor dialog. Now
even that makes NetBeans freeze almost 100% of the time. This practically
renders NetBeans *unusable* on macOS.
NetBeans IDE 8.2 (Build 201609300101), Patch 2
Java 1.8.0_162
Mac OS X Version 10.13.4
Note that, as opposed to what was claimed in older tickets, the problems does
*not* go away with different lool settings.
was (Author: thomas.corte):
Not sure why, but this issues seems to have gotten worse with the latest macOS
update. Previously, I was able to circumvent the freezing most of the time by
using only the keyboard (instead of the mouse) to use the refactor dialog. Now
even that makes NetBeans freeze almost 100% of the time. This practically
renders NetBeans *unusable* on macOS.
NetBeans IDE 8.2 (Build 201609300101), Patch 2
Java 1.8.0_162
Mac OS X Version 10.13.4
Note that, as opposed to what was claimed in older tickets, the problems does
*not* go away with different lool settings.
> Netbeans sometimes freezes when showing any refactor dialog when running with
> jdk 1.8.0_152-b16 or later
>
>
> Key: NETBEANS-373
> URL: https://issues.apache.org/jira/browse/NETBEANS-373
> Project: NetBeans
> Issue Type: Bug
> Components: java - Refactoring
>Affects Versions: 8.2, 9.0
> Environment: Mac
>Reporter: Austin Stephens
>Assignee: Thomas Corte
>Priority: Blocker
> Attachments: Screen Shot 2018-04-02 at 11.22.11 AM.png, Screen Shot
> 2018-04-02 at 11.23.15 AM.png, nbpresenter.diff
>
>
> Sometimes (or almost always), when you try to do some refactor action,
> NetBeans freezes. It appears that a lock is obtained on a panel when the
> dialog is shown, and the AppKit Thread tries to get the lock while trying to
> add an accessible listener to it.
> AppKit Thread:
> {code:java}
> Container.addContainerListener:2142
> Container$AccessibleAWTContainer.addPropertyChangeListener:3885
> JComponent$AccessibleJComponent.addPropertyChangeListener:3765
> Hidden Source Calls
> CAccessible.addNotificationListeners:102
> CAccessible.:84
> CAccessible.getCAccessible:60
> {code}
> EDT Thread:
> {code:java}
> Hidden Source Calls
> Unsafe.park
> LockSupport.park:194
> AbstractQueuedSynchronizer$ConditionObject.await:2062
> EventQueue.getNextEvent:557
> EventDispatchThread.pumpOneEventForFilters:173
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForFilter:117
> WaitDispatchSupport$2.run:190
> WaitDispatchSupport$4.run:235
> WaitDispatchSupport$4.run:233
> AccessController.doPrivileged
> WaitDispatchSupport.enter:233
> Dialog.show:1070
> NbPresenter.superShow:1060
> NbPresenter.doShow:1110
> NbPresenter.run:1082
> NbPresenter.run:105
> NbMutexEventProvider$Event.doEventAccess:115
> NbMutexEventProvider$Event.readAccess:75
> LazyMutexImplementation.readAccess:71
> Mutex.readAccess:193
> NbPresenter.show:1067
> Component.show:1669
> Component.setVisible:1616
> Window.setVisible:1017
> Dialog.setVisible:1005
> ParametersPanel.showDialog:674
> RefactoringPanel.refresh:660
> RefactoringPanel.:144
> UI.openRefactoringUI:61
> ContextAnalyzer$4.show:648
> ContextAnalyzer$TextComponentTask.run:369
> RefactoringActionsProvider.doFindUsages:232
> ActionsImplementationFactory.doFindUsages:91
> WhereUsedAction.performAction:52
> RefactoringGlobalAction$ContextAction.actionPerformed:172
> TopComponent.processKeyBinding:1151
> JComponent.processKeyBindings:2963
> JComponent.processKeyEvent:2863
> Component.processEvent:6355
> Container.processEvent:2259
> Component.dispatchEventImpl:4961
> Container.dispatchEventImpl:2317
> Component.dispatchEvent:4793
> KeyboardFocusManager.redispatchEvent:1955
> DefaultKeyboardFocusManager.dispatchKeyEvent:827
> DefaultKeyboardFocusManager.preDispatchKeyEvent:1096
> DefaultKeyboardFocusManager.typeAheadAssertions:966
> DefaultKeyboardFocusManager.dispatchEvent:792
> Component.dispatchEventImpl:4842
> Container.dispatchEventImpl:2317
> Window.dispatchEventImpl:2758
> Component.dispatchEvent:4793
> EventQueue.dispatchEventImpl:766
> EventQueue.access$500:97
>
[jira] [Comment Edited] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later
[
https://issues.apache.org/jira/browse/NETBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428986#comment-16428986
]
Austin Stephens edited comment on NETBEANS-373 at 4/6/18 9:11 PM:
--
Why is `ParametersPanel.showDialog` (in refactoring.api) `synchronized` anyway?
I tried to get a blame on that line, and it goes back to 10/24/2006 with what
appears to be the creation of the file in the repo from somewhere else... Does
anyone happen to have a copy of the old CVS repo anywhere? The revision in
question has the tag of "{color:#00}after_retouche_2006_merge_trunk{color}"
was (Author: sir intellegence):
Why is `ParametersPanel.showDialog` (in refactoring.api) `synchronized` anyway?
I tried to get a blame on that line, and it goes back to 10/24/2006 with what
appears to be the creation of the file in the repo from somewhere else... Does
anyone happen to have a copy of the old CVS repo anywhere?
> Netbeans sometimes freezes when showing any refactor dialog when running with
> jdk 1.8.0_152-b16 or later
>
>
> Key: NETBEANS-373
> URL: https://issues.apache.org/jira/browse/NETBEANS-373
> Project: NetBeans
> Issue Type: Bug
> Components: java - Refactoring
>Affects Versions: 8.2, 9.0
> Environment: Mac
>Reporter: Austin Stephens
>Priority: Blocker
> Attachments: Screen Shot 2018-04-02 at 11.22.11 AM.png, Screen Shot
> 2018-04-02 at 11.23.15 AM.png, nbpresenter.diff
>
>
> Sometimes (or almost always), when you try to do some refactor action,
> NetBeans freezes. It appears that a lock is obtained on a panel when the
> dialog is shown, and the AppKit Thread tries to get the lock while trying to
> add an accessible listener to it.
> AppKit Thread:
> {code:java}
> Container.addContainerListener:2142
> Container$AccessibleAWTContainer.addPropertyChangeListener:3885
> JComponent$AccessibleJComponent.addPropertyChangeListener:3765
> Hidden Source Calls
> CAccessible.addNotificationListeners:102
> CAccessible.:84
> CAccessible.getCAccessible:60
> {code}
> EDT Thread:
> {code:java}
> Hidden Source Calls
> Unsafe.park
> LockSupport.park:194
> AbstractQueuedSynchronizer$ConditionObject.await:2062
> EventQueue.getNextEvent:557
> EventDispatchThread.pumpOneEventForFilters:173
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForFilter:117
> WaitDispatchSupport$2.run:190
> WaitDispatchSupport$4.run:235
> WaitDispatchSupport$4.run:233
> AccessController.doPrivileged
> WaitDispatchSupport.enter:233
> Dialog.show:1070
> NbPresenter.superShow:1060
> NbPresenter.doShow:1110
> NbPresenter.run:1082
> NbPresenter.run:105
> NbMutexEventProvider$Event.doEventAccess:115
> NbMutexEventProvider$Event.readAccess:75
> LazyMutexImplementation.readAccess:71
> Mutex.readAccess:193
> NbPresenter.show:1067
> Component.show:1669
> Component.setVisible:1616
> Window.setVisible:1017
> Dialog.setVisible:1005
> ParametersPanel.showDialog:674
> RefactoringPanel.refresh:660
> RefactoringPanel.:144
> UI.openRefactoringUI:61
> ContextAnalyzer$4.show:648
> ContextAnalyzer$TextComponentTask.run:369
> RefactoringActionsProvider.doFindUsages:232
> ActionsImplementationFactory.doFindUsages:91
> WhereUsedAction.performAction:52
> RefactoringGlobalAction$ContextAction.actionPerformed:172
> TopComponent.processKeyBinding:1151
> JComponent.processKeyBindings:2963
> JComponent.processKeyEvent:2863
> Component.processEvent:6355
> Container.processEvent:2259
> Component.dispatchEventImpl:4961
> Container.dispatchEventImpl:2317
> Component.dispatchEvent:4793
> KeyboardFocusManager.redispatchEvent:1955
> DefaultKeyboardFocusManager.dispatchKeyEvent:827
> DefaultKeyboardFocusManager.preDispatchKeyEvent:1096
> DefaultKeyboardFocusManager.typeAheadAssertions:966
> DefaultKeyboardFocusManager.dispatchEvent:792
> Component.dispatchEventImpl:4842
> Container.dispatchEventImpl:2317
> Window.dispatchEventImpl:2758
> Component.dispatchEvent:4793
> EventQueue.dispatchEventImpl:766
> EventQueue.access$500:97
> EventQueue$3.run:717
> EventQueue$3.run:711
> AccessController.doPrivileged
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:99
> EventQueue$4.run:739
> EventQueue$4.run:737
> AccessController.doPrivileged
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89
> EventQueue.dispatchEvent:736
> TimableEventQueue.dispatchEvent:136
>
[jira] [Comment Edited] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later
[
https://issues.apache.org/jira/browse/NETBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16422817#comment-16422817
]
Austin Stephens edited comment on NETBEANS-373 at 4/2/18 5:31 PM:
--
I have added some screen shots showing any outstanding locks on the stack. It
looks like it is syncing on "this" and not the tree lock.
In Component:
{code:java}
public synchronized void addContainerListener(ContainerListener l) {
{code}
In ParametersPanel (that calls show)
{code:java}
public synchronized RefactoringSession showDialog() {
{code}
was (Author: sir intellegence):
I have added some screen shots showing any outstanding locks on the stack. It
looks like it is syncing on "this" and not the tree lock.
> Netbeans sometimes freezes when showing any refactor dialog when running with
> jdk 1.8.0_152-b16 or later
>
>
> Key: NETBEANS-373
> URL: https://issues.apache.org/jira/browse/NETBEANS-373
> Project: NetBeans
> Issue Type: Bug
> Components: java - Refactoring
>Affects Versions: 8.2, 9.0
> Environment: Mac
>Reporter: Austin Stephens
>Priority: Blocker
> Attachments: Screen Shot 2018-04-02 at 11.22.11 AM.png, Screen Shot
> 2018-04-02 at 11.23.15 AM.png, nbpresenter.diff
>
>
> Sometimes (or almost always), when you try to do some refactor action,
> NetBeans freezes. It appears that a lock is obtained on a panel when the
> dialog is shown, and the AppKit Thread tries to get the lock while trying to
> add an accessible listener to it.
> AppKit Thread:
> {code:java}
> Container.addContainerListener:2142
> Container$AccessibleAWTContainer.addPropertyChangeListener:3885
> JComponent$AccessibleJComponent.addPropertyChangeListener:3765
> Hidden Source Calls
> CAccessible.addNotificationListeners:102
> CAccessible.:84
> CAccessible.getCAccessible:60
> {code}
> EDT Thread:
> {code:java}
> Hidden Source Calls
> Unsafe.park
> LockSupport.park:194
> AbstractQueuedSynchronizer$ConditionObject.await:2062
> EventQueue.getNextEvent:557
> EventDispatchThread.pumpOneEventForFilters:173
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForFilter:117
> WaitDispatchSupport$2.run:190
> WaitDispatchSupport$4.run:235
> WaitDispatchSupport$4.run:233
> AccessController.doPrivileged
> WaitDispatchSupport.enter:233
> Dialog.show:1070
> NbPresenter.superShow:1060
> NbPresenter.doShow:1110
> NbPresenter.run:1082
> NbPresenter.run:105
> NbMutexEventProvider$Event.doEventAccess:115
> NbMutexEventProvider$Event.readAccess:75
> LazyMutexImplementation.readAccess:71
> Mutex.readAccess:193
> NbPresenter.show:1067
> Component.show:1669
> Component.setVisible:1616
> Window.setVisible:1017
> Dialog.setVisible:1005
> ParametersPanel.showDialog:674
> RefactoringPanel.refresh:660
> RefactoringPanel.:144
> UI.openRefactoringUI:61
> ContextAnalyzer$4.show:648
> ContextAnalyzer$TextComponentTask.run:369
> RefactoringActionsProvider.doFindUsages:232
> ActionsImplementationFactory.doFindUsages:91
> WhereUsedAction.performAction:52
> RefactoringGlobalAction$ContextAction.actionPerformed:172
> TopComponent.processKeyBinding:1151
> JComponent.processKeyBindings:2963
> JComponent.processKeyEvent:2863
> Component.processEvent:6355
> Container.processEvent:2259
> Component.dispatchEventImpl:4961
> Container.dispatchEventImpl:2317
> Component.dispatchEvent:4793
> KeyboardFocusManager.redispatchEvent:1955
> DefaultKeyboardFocusManager.dispatchKeyEvent:827
> DefaultKeyboardFocusManager.preDispatchKeyEvent:1096
> DefaultKeyboardFocusManager.typeAheadAssertions:966
> DefaultKeyboardFocusManager.dispatchEvent:792
> Component.dispatchEventImpl:4842
> Container.dispatchEventImpl:2317
> Window.dispatchEventImpl:2758
> Component.dispatchEvent:4793
> EventQueue.dispatchEventImpl:766
> EventQueue.access$500:97
> EventQueue$3.run:717
> EventQueue$3.run:711
> AccessController.doPrivileged
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:99
> EventQueue$4.run:739
> EventQueue$4.run:737
> AccessController.doPrivileged
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89
> EventQueue.dispatchEvent:736
> TimableEventQueue.dispatchEvent:136
> EventDispatchThread.pumpOneEventForFilters:199
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForHierarchy:113
> EventDispatchThread.pumpEvents:109
>
[jira] [Comment Edited] (NETBEANS-373) Netbeans sometimes freezes when showing any refactor dialog when running with jdk 1.8.0_152-b16 or later
[
https://issues.apache.org/jira/browse/NETBEANS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406335#comment-16406335
]
Fabian Bahle edited comment on NETBEANS-373 at 3/20/18 2:02 PM:
I have exactly the same issue and not only on NetBeans 8.2, also on NetBeans
9.0 beta. I'm on macOS High Sierra and JDK 1.8.0_162
It's really annoying that the IDE always freezes when I try to refactor/rename
something.
As soon as the refactor dialog shows up the IDE freezes.
EDIT:
FYI: Just switched to JDK 1.8.0_151 and it works again
was (Author: funfried):
I have exactly the same issue and not only on NetBeans 8.2, also on NetBeans
9.0 beta. I'm on macOS High Sierra and JDK 1.8.0_162
It's really annoying that the IDE always freezes when I try to refactor/rename
something.
As soon as the refactor dialog shows up the IDE freezes.
> Netbeans sometimes freezes when showing any refactor dialog when running with
> jdk 1.8.0_152-b16 or later
>
>
> Key: NETBEANS-373
> URL: https://issues.apache.org/jira/browse/NETBEANS-373
> Project: NetBeans
> Issue Type: Bug
> Components: java - Refactoring
>Affects Versions: 8.2, 9.0
> Environment: Mac
>Reporter: Austin Stephens
>Priority: Blocker
> Fix For: 9.0
>
>
> Sometimes (or almost always), when you try to do some refactor action,
> NetBeans freezes. It appears that a lock is obtained on a panel when the
> dialog is shown, and the AppKit Thread tries to get the lock while trying to
> add an accessible listener to it.
> AppKit Thread:
> {code:java}
> Container.addContainerListener:2142
> Container$AccessibleAWTContainer.addPropertyChangeListener:3885
> JComponent$AccessibleJComponent.addPropertyChangeListener:3765
> Hidden Source Calls
> CAccessible.addNotificationListeners:102
> CAccessible.:84
> CAccessible.getCAccessible:60
> {code}
> EDT Thread:
> {code:java}
> Hidden Source Calls
> Unsafe.park
> LockSupport.park:194
> AbstractQueuedSynchronizer$ConditionObject.await:2062
> EventQueue.getNextEvent:557
> EventDispatchThread.pumpOneEventForFilters:173
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForFilter:117
> WaitDispatchSupport$2.run:190
> WaitDispatchSupport$4.run:235
> WaitDispatchSupport$4.run:233
> AccessController.doPrivileged
> WaitDispatchSupport.enter:233
> Dialog.show:1070
> NbPresenter.superShow:1060
> NbPresenter.doShow:1110
> NbPresenter.run:1082
> NbPresenter.run:105
> NbMutexEventProvider$Event.doEventAccess:115
> NbMutexEventProvider$Event.readAccess:75
> LazyMutexImplementation.readAccess:71
> Mutex.readAccess:193
> NbPresenter.show:1067
> Component.show:1669
> Component.setVisible:1616
> Window.setVisible:1017
> Dialog.setVisible:1005
> ParametersPanel.showDialog:674
> RefactoringPanel.refresh:660
> RefactoringPanel.:144
> UI.openRefactoringUI:61
> ContextAnalyzer$4.show:648
> ContextAnalyzer$TextComponentTask.run:369
> RefactoringActionsProvider.doFindUsages:232
> ActionsImplementationFactory.doFindUsages:91
> WhereUsedAction.performAction:52
> RefactoringGlobalAction$ContextAction.actionPerformed:172
> TopComponent.processKeyBinding:1151
> JComponent.processKeyBindings:2963
> JComponent.processKeyEvent:2863
> Component.processEvent:6355
> Container.processEvent:2259
> Component.dispatchEventImpl:4961
> Container.dispatchEventImpl:2317
> Component.dispatchEvent:4793
> KeyboardFocusManager.redispatchEvent:1955
> DefaultKeyboardFocusManager.dispatchKeyEvent:827
> DefaultKeyboardFocusManager.preDispatchKeyEvent:1096
> DefaultKeyboardFocusManager.typeAheadAssertions:966
> DefaultKeyboardFocusManager.dispatchEvent:792
> Component.dispatchEventImpl:4842
> Container.dispatchEventImpl:2317
> Window.dispatchEventImpl:2758
> Component.dispatchEvent:4793
> EventQueue.dispatchEventImpl:766
> EventQueue.access$500:97
> EventQueue$3.run:717
> EventQueue$3.run:711
> AccessController.doPrivileged
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:99
> EventQueue$4.run:739
> EventQueue$4.run:737
> AccessController.doPrivileged
> ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege:89
> EventQueue.dispatchEvent:736
> TimableEventQueue.dispatchEvent:136
> EventDispatchThread.pumpOneEventForFilters:199
> EventDispatchThread.pumpEventsForFilter:124
> EventDispatchThread.pumpEventsForHierarchy:113
>
