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: | Auto-complete takes forever when file is damaged | ||
---|---|---|---|
Product: | editor | Reporter: | ecerichter |
Component: | CSL (API & infrastructure) | Assignee: | Svata Dedic <sdedic> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | exceptions_reporter, issues, jlahoda, mmirilovic, vriha |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 7.3 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
IDE log
Video of autocomplete on uncompilable file Snapshot of the ide - hope this helps |
Description
ecerichter
2013-02-09 05:04:52 UTC
Created attachment 131185 [details]
IDE log
Created attachment 131186 [details]
Video of autocomplete on uncompilable file
Created attachment 131187 [details]
Snapshot of the ide - hope this helps
From the attached IDE snapshot it seems like a deadlock between BreadCrumbsScanningTask and CSL's ClassMemberPanelUI. To expand on Dusan's evaluation: the Java's breadcrumbs task has the parser lock and wants the Children.MUTEX, which the CSL Navigator expander holds the Children.MUTEX and wants the parser lock. I really would like to avoid changing the Java's breadcrumbs, as flipping the lock order there would prevent using cancellable computation (note that this case proves that the CSL Navigator expand runs after the navigator's context has already been changed, I would like prevent situations like this in Java's breadcrumbs). Flipping the lock order in CSL may be possible - instead of calling getNestedItems while creating the node (which apparently is done under the lock), call it in Children.addNotify - I think addNotify should be called outside the Children.MUTEX. *** Bug 226887 has been marked as a duplicate of this bug. *** Changeset: 8c787f04afc0 Author: Svata Dedic <sdedic@netbeans.org> Date: 2013-03-08 11:08 Message: Calling nestedItems with potential parsing outside children mutex For testing, a PHP or CND distribution will be necessary, so the new HTML5 navigator is not present. The actual deadlock was between HTML (old style) node expansion in Navigator and breadcrumbs task. Lada, could you please verify the fix ? Thanks in advance ! I'll try it once it gets to jet-main/trunk build, but I can't reproduce it in 7.3 as such. I tried JavaEE distribution, PHP and no luck :/ Integrated into 'main-golden', will be available in build *201303122300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/8c787f04afc0 User: Svata Dedic <sdedic@netbeans.org> Log: Issue #225925 - Auto-complete takes forever when file is damaged: fixed Calling nestedItems with potential parsing outside children mutex I can "verify" it only because I cannot reproduce it but I cannot do that even in 7.3. Martin Kanak also didn't reproduce it in 7.3 Since I cannot verify it and it seems to be quite rare case, I'd vote not to put it to patch1. JirkaP promised to try it as well, thanks Unfortunately I cannot reproduce it as well Edson can you, please, try daily build if it still happen to you? Thanks (In reply to comment #14) > Unfortunately I cannot reproduce it as well > Edson can you, please, try daily build if it still happen to you? > Thanks Not reproducible in DEV 201303052300. Regards, Edson Thanks! Integrated into 'releases', will be available in build *201303141828* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/f4563a1ad0b1 User: Svata Dedic <sdedic@netbeans.org> Log: Issue #225925 - Auto-complete takes forever when file is damaged: fixed Calling nestedItems with potential parsing outside children mutex *** Bug 226856 has been marked as a duplicate of this bug. *** |