Rangi Keen created NETBEANS-1834: ------------------------------------ Summary: Possible race condition in ExplorerActionsImpl Key: NETBEANS-1834 URL: https://issues.apache.org/jira/browse/NETBEANS-1834 Project: NetBeans Issue Type: Bug Components: platform - Explorer Affects Versions: 8.2 Reporter: Rangi Keen Attachments: ExplorerActionsImpl.Race.patch
{{ExplorerActionsImpl}} uses a background thread to determine the enabled state of its actions. The background thread calls {{ExplorerActionsImpl.BaseAction.toEnabled(boolean)}} to set the target state from the background thread and then queues up a call on the {{EventQueue}} to be run on the EDT that calls {{ExplorerActionsImpl.BaseAction.syncEnable()}} which calls {{setEnabled}} if {{toEnable}} is non-null. However, since the check for {{toEnable != null}}, the use of {{toEnable}} in the call to {{setEnabled}}, and the set of {{toEnable = null}} are all on separate lines there is the possibility that another call to {{toEnabled(boolean)}} will set {{toEnable}} after the call to {{setEnabled}} but before it is reset to null. The end result is that if the new value of {{toEnable}} was different from the one being acted upon, the action may end up in the wrong state. One solution (in [^ExplorerActionsImpl.Race.patch]) is to use an {{AtomicInteger}} to get the value of {{toEnable}} and set it to null (or {{NO_CHANGE}}) atomically, thus avoiding the race condition. I don't have a reproducible case in the NetBeans IDE, but we encountered this in our custom application using the NetBeans platform. The attached patch solved the issue in our case. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists