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.
Product Version = NetBeans IDE 7.3 RC2 (Build 201302050851) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.7.0_13 Runtime = Java HotSpot(TM) 64-Bit Server VM 23.7-b01 This is not expected, and as far as I remember, previous versions where able to deal with incomplete/incorrect (not compilable) files. I would consider this issue a regression of the autocomplete functionality. See attached video to get an idea of the issue. I did give up after 15 minutes, but it would be running forever. I do expect that autocomplete (specially since I was typing a Integer... method call) to be able to ignore uncompilable files and provide suggestions for me (in less than a second, as normally does). Instead, seems that uncompilable files bring autocomplte to state that it stops working until I fix the file.
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. ***