This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Race condition at SimpleProxyLookup.ProxyResult.updateLookup | ||
---|---|---|---|
Product: | platform | Reporter: | andreas_50931 |
Component: | Lookup | Assignee: | Jaroslav Havlin <jhavlin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mkleint, ovrabec, tstupka |
Priority: | P2 | ||
Version: | 8.0 | ||
Hardware: | All | ||
OS: | Mac OS X | ||
Issue Type: | DEFECT | Exception Reporter: | 210610 |
Bug Depends on: | |||
Bug Blocks: | 246421 | ||
Attachments: | stacktrace |
Description
andreas_50931
2015-02-10 17:51:51 UTC
Created attachment 151933 [details]
stacktrace
Almost same here. I delete several files from the file search results when Netbeans hung up. The files reappeared after reopening. The bug can be reproduced. org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:169) it collects events + listeners (collectFires) and stores them in an arraylist -> the list contains over 70 mil. items ;-( Sorry jardo, i'm reassigning to you. Let's look at this together. This is very likely causing bug #246421 - it's a slowness caused by iterating over the items of the collected events+listeners - and because that array contains millions of listeners the slowness is imminent. ufff, there are over 90 000 instances of org.netbeans.modules.project.ui.actions.FileAction$1($2), lot of them (if not all) being part of the mentioned lookup listeners. seems to happen only on Mac - both this and bug 246421 Further peace of evaluation: the list in ProxyLookups.setLookups contains duplicate items: i can see e.g. two pairs: [LookupEvent(#599) -> SimpleProxyLookup$ProxyResult(#7), $Proxy7(#1266) -> WeakListImpl$ProxyListener(#32761) [LookupEvent(#718) -> SimpleProxyLookup$ProxyResult(#7), $Proxy7(#1266) -> WeakListImpl$ProxyListener(#32761) i expect a lot of other duplicate instances of the same event+listener Synchronization in ProxyLookup$R.removeLookupListener(), which may be related to this bug, fixed in http://hg.netbeans.org/core-main/rev/8913c52bc2fc. Another cause of the problem can be high number of lookup listeners attached to lookup results. In the heap dump, the biggest instance of LookupListener[] contains several thousand items. The listeners are of type SimpleProxyLookup$WeakResult, and the array belongs to an instance of type ProxyLookup$R. Some extra listeners might be added (due to race condition) at SimpleProxyLookup.ProxyResult.updateLookup, line 226, just after the for-loop. Reassigning. Thank you, Jarda. Tomas Hurka observed that some snapshots from bug 246421 show that thread MainWndMac intensively retrieves items from SimpleProxyLookup$ProxyResult (e.g. snapshot 778046). Keeping only one task with this operation scheduled could help. http://hg.netbeans.org/core-main/rev/f4edb7b0adfe I did bunch of changes to make the behavior more robust. Parent of five of them is http://hg.netbeans.org/ergonomics/rev/ff58c5c460a6 There were plenty of synchronization bugs which I demonstrated by encapsulating access to mutable fields into getters and setters and guarded it by Thread.holdsLock. I have not managed to demonstrate a case where two listeners (WeakResult) are added to the same result, but I created a test case showing that it is quite common to create and add many WeakResult instances needlessly. I fixed that. Now waiting for ergonomics build to report failures. It remains to be seen whether the changes in SimpleProxyLookup affect the global problem or not - but that is more work than I can dedicate on a weekend. Passing back to Jarda HavlĂn. ergonomics build succeeded. My change is in main-silver: http://hg.netbeans.org/main-silver/rev/ff58c5c460a6 (In reply to Ondrej Vrabec from comment #4) > ufff, there are over 90 000 instances of > org.netbeans.modules.project.ui.actions.FileAction$1($2), > lot of them (if not all) being part of the mentioned lookup listeners. http://hg.netbeans.org/core-main/rev/13fa7add8dd2 Code simplified (less new objects created during refresh), using sliding task to schedule the refresh operation. (In reply to Jaroslav Tulach from comment #11) > ergonomics build succeeded. My change is in main-silver: > http://hg.netbeans.org/main-silver/rev/ff58c5c460a6 Thank you very much. (In reply to Jaroslav Tulach from comment #10) > It remains to be seen whether the changes in SimpleProxyLookup affect the > global problem or not. I'm not sure how to verify this. We have fixed several suspicious places, so I think we can close the issue and wait. If new reports come from future builds, we'll reopen this bug. Integrated into 'main-silver', will be available in build *201507220303* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/330a6563f0ca User: Jaroslav Tulach <jtulach@netbeans.org> Log: #250349: Guarding thread-safe access to lastListener Integrated into 'main-silver', will be available in build *201507230001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/13fa7add8dd2 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #250349: Many FileAction$1 instances in a RequestProcessor |