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.

Bug 244522 - Foundation 5 SASS = 100% for all CPUS and OutOfMemory Exception
Summary: Foundation 5 SASS = 100% for all CPUS and OutOfMemory Exception
Status: RESOLVED FIXED
Alias: None
Product: javascript
Classification: Unclassified
Component: Editor (show other bugs)
Version: 8.0
Hardware: PC Mac OS X
: P1 normal (vote)
Assignee: Petr Pisl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-15 22:26 UTC by Zoff
Modified: 2014-07-31 12:20 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
JVM crash log (52.28 KB, text/x-log)
2014-05-16 06:30 UTC, Vladimir Riha
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Zoff 2014-05-15 22:26:16 UTC
I just did the following:

1) Create a Foundation SASS project with the following command suggested in documentation: http://foundation.zurb.com/docs/sass.html

foundation new PROJECT_NAME --libsass

2) In Netbeans create a new "HTML5 Application from existing sources" and point it to the folder created by 1)

Project starts opening occupying all cpus at 100% and filling memory.
Netbeans is no longer responding.

I repeated the steps even in a new Project Group without any other project.
Comment 1 Vladimir Riha 2014-05-16 06:30:13 UTC
Created attachment 147287 [details]
JVM crash log

Reproducible in NetBeans 8.0, in my case JVM crashed. From the heap dump I think this is related to CSS/SCSS. I uploaded heap dump to deadlock.
Comment 2 Marek Fukala 2014-07-09 10:23:04 UTC
can you please Vlado attach here the generated project so I do not have to bother with the setup?
Comment 3 Vladimir Riha 2014-07-09 10:44:42 UTC
Sure, will do asap
Comment 4 Vladimir Riha 2014-07-09 11:02:15 UTC
Here it is, use File->Download to download entire zip archive


https://drive.google.com/file/d/0B6Sd5ov8j7IUaVU5a1JLUkZLa0k/edit?usp=sharing
Comment 5 Marek Fukala 2014-07-09 11:50:37 UTC
Thank you Vlado!
Comment 6 Marek Fukala 2014-07-09 15:37:21 UTC
The endless project scanning is caused by javascript2.editor module. Following code seems to run endlessly:

"RepositoryUpdater.worker" #27 daemon prio=1 os_prio=31 tid=0x00007fff06287800 nid=0xfa03 runnable [0x000000012573c000]
   java.lang.Thread.State: RUNNABLE
	at org.netbeans.api.lexer.TokenSequence.isInvalid(TokenSequence.java:820)
	at org.netbeans.api.lexer.TokenSequence.checkValid(TokenSequence.java:804)
	at org.netbeans.api.lexer.TokenSequence.movePrevious(TokenSequence.java:532)
	- locked <0x00000007af725ab8> (a org.netbeans.lib.lexer.BatchTokenList)
	at org.netbeans.modules.javascript2.editor.doc.spi.JsDocumentationHolder.getEndOffsetOfAssociatedComment(JsDocumentationHolder.java:258)
	at org.netbeans.modules.javascript2.editor.doc.spi.JsDocumentationHolder.getCommentForOffset(JsDocumentationHolder.java:234)
	at org.netbeans.modules.javascript2.editor.doc.spi.JsDocumentationHolder.getDocumentation(JsDocumentationHolder.java:155)
	at org.netbeans.modules.javascript2.editor.model.impl.ModelElementFactory.create(ModelElementFactory.java:292)
	at org.netbeans.modules.javascript2.editor.model.impl.ModelVisitor.enter(ModelVisitor.java:1125)
	at jdk.nashorn.internal.ir.PropertyNode.accept(PropertyNode.java:91)
	at jdk.nashorn.internal.ir.ObjectNode.accept(ObjectNode.java:88)
	at jdk.nashorn.internal.ir.BinaryNode.accept(BinaryNode.java:178)
	at jdk.nashorn.internal.ir.ExecuteNode.accept(ExecuteNode.java:89)
	at org.netbeans.modules.javascript2.editor.model.impl.ModelVisitor.enter(ModelVisitor.java:755)
	at jdk.nashorn.internal.ir.FunctionNode.accept(FunctionNode.java:291)
	at org.netbeans.modules.javascript2.editor.model.Model.getModelVisitor(Model.java:156)
	- locked <0x00000007af723948> (a org.netbeans.modules.javascript2.editor.model.Model)
	at org.netbeans.modules.javascript2.editor.model.Model.getGlobalObject(Model.java:458)
	at org.netbeans.modules.javascript2.editor.index.JsIndexer.index(JsIndexer.java:105)
	at org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$3.run(Indexable.java:248)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:283)
Comment 7 Petr Pisl 2014-07-24 09:49:59 UTC
I have tried the project and the scanning was finished after 168 seconds. Vlado, are you able to reproduce the endless scanning?
Comment 8 Marek Fukala 2014-07-24 10:42:49 UTC
As I wrote: "it seems to run endlessly". Haven't tried more than few minutes.
Comment 9 Vladimir Riha 2014-07-24 11:20:46 UTC
I'll give it a try later today but I was getting OOM when I tried it.
Comment 10 Vladimir Riha 2014-07-24 14:32:05 UTC
I can reproduce the OOM in 8.0, but not in Dev, it takes 2-3 minutes but scanning does finish.

Do you want the heap dump or IDE log?
Comment 11 Marek Fukala 2014-07-24 14:37:12 UTC
Please attach the heap dump.
Comment 12 Vladimir Riha 2014-07-24 15:15:16 UTC
Heap dump and IDE logs are in this archive

https://drive.google.com/file/d/0B6Sd5ov8j7IUSXBGdHdxQ1hkLUU/edit?usp=sharing
Comment 13 Petr Pisl 2014-07-31 12:20:00 UTC
In the attached heap dump there are almost 6 millions instances of org.netbeans.modules.css.lib.TokenNode and the same amount of org.antlr.runtime.CommonToken.

Marek did a few fixes and it can be the reason why we can not reproduce it now. Closing as fixed.