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.
I added my PHP include path (/usr/share/php5 and /usr/share/php folders) to the IDE global PHP include path - and after long time this exception occurs. SEVERE [global] Root: /usr/share/php5 File: Tags.php Bootpath: ClassPath[Entry[file:/usr/share/php5/]] Classpath: ClassPath[Entry[file:/usr/share/php5/]] Sourcepath: ClassPath[Entry[file:/usr/share/php5/]] Caused by: java.lang.OutOfMemoryError: Java heap space at org.netbeans.lib.lexer.LAState$LargeState.<init>(LAState.java:400) at org.netbeans.lib.lexer.LAState$LargeState.upgrade(LAState.java:412) at org.netbeans.lib.lexer.LAState.add(LAState.java:114) at org.netbeans.lib.lexer.inc.IncTokenList.tokenOrEmbeddingImpl(IncTokenList.java:191) at org.netbeans.lib.lexer.inc.IncTokenList.tokenOrEmbedding(IncTokenList.java:180) at org.netbeans.api.lexer.TokenSequence.moveNext(TokenSequence.java:454) at org.netbeans.modules.javascript.editing.embedding.JsModel.extractJavaScriptFromPHP(JsModel.java:255) at org.netbeans.modules.javascript.editing.embedding.JsModel.getJsCode(JsModel.java:154) at org.netbeans.modules.javascript.editing.embedding.JsTranslatedSource.getSource(JsTranslatedSource.java:69) at org.netbeans.napi.gsfret.source.ParserTaskImpl.parse(ParserTaskImpl.java:139) at org.netbeans.modules.gsfret.source.usages.RepositoryUpdater.batchCompile(RepositoryUpdater.java:2040) at org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.updateFolder(RepositoryUpdater.java:1405) at org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.scanRoots(RepositoryUpdater.java:1130) at org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.access$1900 (RepositoryUpdater.java:652) at org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:790) at org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker$1.run(RepositoryUpdater.java:680) at org.netbeans.modules.gsfret.source.usages.ClassIndexManager.writeLock(ClassIndexManager.java:123) at org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:677) at org.netbeans.modules.gsfret.source.usages.RepositoryUpdater$CompileWorker.run(RepositoryUpdater.java:652) at org.netbeans.napi.gsfret.source.Source$CompilationJob.run(Source.java:1300) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) at java.util.concurrent.FutureTask.run(FutureTask.java:123) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Product Version: NetBeans IDE Dev (Build 080805) Java: 1.5.0_16; Java HotSpot(TM) Client VM 1.5.0_16-b02 System: Linux version 2.6.26-gentoo running on i386; UTF-8; cs_CZ (nb)
Additional information: /usr/share/php5 - 42M, 4660 files /usr/share/php - 21M, 1933 files
During indexing, IDE is completely unusable (100% CPU) and after 9 minutes (!) exception occurs. (May or may not be related to the issue #132312.)
This must to be a regression from this Monday, Tuesday or Wednesday.
I'll look at it ASAP
The indexing slowness may be caused by the garbage collector trying to free some memory. There is an issue #143027 filled against javascript support complaining about memory leaks after initial indexing in web project with some javascripts. OTOH I am not sure whether the issue is regression from this week as ppisl claims. I'll try to analyze the heapdumps attached to the other issue.
It must to be regression from this week, because I measured the indexing of php files on Sunday. The indexing of my testing project took 66 seconds. Now after 5 minutes I obtain OutOfMemory.
Just to be sure, I have tried it in this build Product Version: NetBeans IDE Dev (Build 200808040201) Java: 1.6.0_10-beta; Java HotSpot(TM) Client VM 11.0-b12 System: Linux version 2.6.24-19-generic running on i386; UTF-8; en_US (nb) Userdir: /home/petr/.netbeans/de and it works. It really takes "only" 66 seconds, no exception.
The most important thing is, whether this regression is in the beta as well or not. If it's in beta, then has to be fixed. I will try it.
I have just tested Product Version: NetBeans IDE 6.5 Beta (Build 200808070301) Java: 1.6.0_10-beta; Java HotSpot(TM) Client VM 11.0-b12 System: Linux version 2.6.24-19-generic running on i386; UTF-8; en_US (nb) Userdir: /space/tmp/userdir/567 and this build is OK. It doesn't contain the regression. It can not beta stopper.
From looking into the heapdump I guess this is a regression from jtulach's changeset 94375:fef78628ae8e from Aug 4th - he introduced a new static field 'charsets' into DataEditorSupport which seems to indirectly hold all DataObject instancies which used DataEditorSupport to load the content into editor. Jardo, can you please take a look at this issue? It is 100% reproducible if you follow the steps above. I cannot attach the heapdump here so I'll at least make a screenshot of the part I belive is the source of the leak. Let me know if we (or gsf) does something wrong if you belive your change is ok. Thanks
Created attachment 66890 [details] Screenshot of the references from heapdump
The objects are supposed to be held only during save/load. The described behaviour would be quite surprising.
So maybe I am wrong, not completely sure. Will you check it then?
I guess the get in following diff in http://hg.netbeans.org/main/rev/fef78628ae8e shall be remove: } finally { - charsetForSaveAndLoad = null; - charsetForObject = null; + charsets.get(tmpObj); }
changeset: 95246:574db98aeaff tag: tip user: Jaroslav Tulach <jtulach@netbeans.org> date: Fri Aug 08 13:17:11 2008 +0200 summary: #143080: Use remove for cleanup not get
*** Issue 143027 has been marked as a duplicate of this issue. ***
Integrated into 'main-golden', available in build *200808090201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/574db98aeaff User: Jaroslav Tulach <jtulach@netbeans.org> Log: #143080: Use remove for cleanup not get
I can confirm that in todays builds, the problem is not reproducible anymore.
Verified.