Bug 225925 - Auto-complete takes forever when file is damaged
Auto-complete takes forever when file is damaged
Status: VERIFIED FIXED
Product: editor
Classification: Unclassified
Component: CSL (API & infrastructure)
7.3
PC Windows 7
: P2 (vote)
: 7.3.1
Assigned To: Svata Dedic
issues@editor
73patch1-verified
: PERFORMANCE
: 226856 226887 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-09 05:04 UTC by ecerichter
Modified: 2013-06-07 12:01 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
IDE log (459.85 KB, text/plain)
2013-02-09 05:05 UTC, ecerichter
Details
Video of autocomplete on uncompilable file (3.38 MB, video/avi)
2013-02-09 05:06 UTC, ecerichter
Details
Snapshot of the ide - hope this helps (51.25 KB, application/octet-stream)
2013-02-09 05:07 UTC, ecerichter
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ecerichter 2013-02-09 05:04:52 UTC
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.
Comment 1 ecerichter 2013-02-09 05:05:05 UTC
Created attachment 131185 [details]
IDE log
Comment 2 ecerichter 2013-02-09 05:06:42 UTC
Created attachment 131186 [details]
Video of autocomplete on uncompilable file
Comment 3 ecerichter 2013-02-09 05:07:53 UTC
Created attachment 131187 [details]
Snapshot of the ide - hope this helps
Comment 4 Dusan Balek 2013-02-11 09:36:09 UTC
From the attached IDE snapshot it seems like a deadlock between  BreadCrumbsScanningTask and CSL's ClassMemberPanelUI.
Comment 5 Jan Lahoda 2013-02-11 09:46:38 UTC
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.
Comment 6 Milutin Kristofic 2013-03-04 16:26:46 UTC
*** Bug 226887 has been marked as a duplicate of this bug. ***
Comment 7 Svata Dedic 2013-03-08 10:08:40 UTC
Changeset: 8c787f04afc0
Author:    Svata Dedic <sdedic@netbeans.org>
Date:      2013-03-08 11:08
Message:   Calling nestedItems with potential parsing outside children mutex
Comment 8 Svata Dedic 2013-03-08 10:15:52 UTC
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.
Comment 9 Marian Mirilovic 2013-03-08 10:27:27 UTC
Lada, 
could you  please verify the fix ? Thanks in advance !
Comment 10 Vladimir Riha 2013-03-08 11:45:34 UTC
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 :/
Comment 11 Quality Engineering 2013-03-13 02:09:28 UTC
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
Comment 12 Vladimir Riha 2013-03-13 09:40:27 UTC
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
Comment 13 Vladimir Riha 2013-03-13 10:06:49 UTC
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
Comment 14 Jiri Prox 2013-03-13 10:29:57 UTC
Unfortunately I cannot reproduce it as well
Edson can you, please, try daily build if it still happen to you?
Thanks
Comment 15 ecerichter 2013-03-13 12:39:03 UTC
(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
Comment 16 Jiri Prox 2013-03-13 13:11:52 UTC
Thanks!
Comment 17 Quality Engineering 2013-03-14 21:14:33 UTC
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
Comment 18 Svata Dedic 2013-06-07 12:01:13 UTC
*** Bug 226856 has been marked as a duplicate of this bug. ***


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo