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.
Created attachment 123219 [details] jstack output I'm constantly getting into NetBeans stopped responding. Attached is jstack result. Product Version: NetBeans IDE 7.2 (Build 201207171143) Java: 1.7.0_04; Java HotSpot(TM) 64-Bit Server VM 23.0-b21 System: Windows 7 version 6.1 running on amd64; Cp1251; en_US (nb) Groovy and Grails Version: 1.22.1
Clearing out the cache helped to proceed.
*** Bug 215108 has been marked as a duplicate of this bug. ***
Mm, quite weird, it's happening only in some special cases (one of them is attached in the issue 215108).. I'm able to reproduce this only if there is 10+ classes in one groovy file. Do you have any other reproducible test case?
Downgrading to P2. It definitely has to be fixed, but I don't think it's a blocker for 7.3beta as the problem occurs only in a pretty rare cases (files with more than 10 classes - at least I wasn't able to find another reproducible test case).
Created attachment 124506 [details] Reproducible test case
I have a 3rd party big project that uses griffon and groovy which I couldn't share. If there is a way to obtain more information through logs or modified modules - let's do it. Unfortunately, it's just impossible to work on this project in NetBeans. Had to switch to IntelliJ IDEA. Nice workaround. :-)
CCing Tomas. This is the issue I was talking about on Monday, could you please help me with it? It looks that application isn't deadlocked but indexing seems to be suspended for some reason and Code completion thread is waiting for it. And when user tries to make another operation with file, the IDE stops responding because GsfDocument is already locked by code completion thread and AWT is trying to get it's lock. The reproducible test case is: - open attached groovy file - create new line at the beggining of Zodiac.matches method - type "date." and press CTRL+SPACE - while code completion is in progress, try to backspace last char (dot) --> IDE stops responding
After offline discussion requesting a waiver for NetBeans 7.3. The problem occurs only in rare cases and doesn't impact on many users (we have only one reported for the whole release).
Reassigning to Tomas for evaluation.
I just tried to reproduce the problem with the latest build and it seems to be gone (the steps from comment 7 were 100% reproducible earlier). I have absolutely no idea where it had been fixed, so closing as WORKSFORME Reporter, if you get into this problem again, please reopen the issue. Thanks!
The issue is still there. I am using NetBeans 8 and Java 8 currently. Windows 7 x64. Looks like NetBeans completely hangs when trying to find autocomplete suggestions. The bug is critical as Groovy functionality is totally broken in fact, you cannot use NetBeans wotk with Groovy because of this.
*** Bug 239696 has been marked as a duplicate of this bug. ***
JavaIndexerWorker.getCompileTupleIterator() seems to be using different approaches for getting completion results (in case of more than ten files it run separate tasks using CompletionService, otherwise it use sequential approach and one task for those few files). I don't understand details but from what I can see Java is passing exactly one CompileTuple per file. On the other hand Groovy is passing one CompileTuple per declared class. Because of that, if we create a single groovy file with ten or more inner classes, JavaIndexerWorker.getCompileTupleIterator() consider it as multiple files and run separate task for each one of them. But all of them needs to access the same file causing deadlock? Just guessing the last part. Not sure if the current JavaIndexerWorker implementation should be improved somehow or if it's more like a problem of Groovy which is passing more than one CompileTuple per file. Tomasi, what do you think?? Going to attach simplest reproducible test project.
Created attachment 148384 [details] Simplest test project
Created attachment 148388 [details] reproduce project I too have the same issue. I uploaded a project to reproduce this issue. Thanks, Amber.
Temporary work around: Go to Tools - Options - Editor - [Code Completion] Use the options to turn off auto Code Completion. Note: invoking Code Completion via Ctrl+Space will still cause NetBeans to freeze, but you can at least progress until the defect is fixed.
>I don't understand details but from what I can see Java is passing exactly one >CompileTuple per file. On the other hand Groovy is passing one CompileTuple per >declared class. Because of that, if we create a single groovy file with ten or more >inner classes, JavaIndexerWorker.getCompileTupleIterator() consider it as multiple >files and run separate task for each one of them. But all of them needs to access the >same file causing deadlock? No, the physical groovy file is not accessed by the CompileWorker in JavaIndexWorker. The groovy file is first translated using VirtualSourceProvider into 10 virtual JavaFileObjects (java stubs for groovy file) and these JavaFileObjects are passed to JavaIndexWorker however the content is already in memory.
OK, the problem is that the prefetch is suspended by the code completion.
fixed jet-main 7b76d61e1094
Thanks a lot Tome !
Fixed unit tests: http://hg.netbeans.org/jet-main/rev/469084c6ecb0
Transplanted into NB 8.0.1: ff3f2727a8b5, cbc8ff188136
Integrated into 'releases/release801', will be available in build *201408071314* or newer. Wait for official and publicly available build. Changeset: http://hg.netbeans.org/releases/rev/ff3f2727a8b5 User: Tomas Zezula <tzezula@netbeans.org> Log: #216992:NetBeans hangs during groovy file editing
Integrated into 'main-silver', will be available in build *201408090001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/7b76d61e1094 User: Tomas Zezula <tzezula@netbeans.org> Log: #216992:NetBeans hangs during groovy file editing