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.
Last night I simply locked my PC & left NetBeans open. This morning when I arrived at work, NetBeans gave me an OutOfMemoryError message + the option to report it. When I tried to do so, it hung. Using VisualVM I created an application snapshot with a heap- and threaddump. When I brought NetBeans to the foreground afterwards, it was a fully black screen (except for the top bar with the window decorations). After restarting NetBeans, it offered me to report again, but failed doing so & told me to report it manually. Product Version: NetBeans IDE Dev (Build 201509130002) Updates: Updates available Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
The snapshot should be at build #1222. Note that this is a VisualVM application snapshot, not just a heap dump. Also, it could be zipped (the size difference was negligible, and I can't remember whether I chose to upload the zipped version or not).
The zipped heap dump that was generated by NetBeans itself is at build #1223.
There is a huge number of FileObject related instances held as class path of HTML5 project.
(In reply to Tomas Hurka from comment #3) > There is a huge number of FileObject related instances held as class path of > HTML5 project. Yes, I had opened about 25 HTML5 projects before leaving, so I assume NetBeans hung while doing its background scanning on them. Of course, you could say: "no wonder it runs out of memory with that many projects open". And I also still had the heap size at its default, so that didn't help either. However, I think there's certainly room for improvement here. Why does NetBeans apparently have to scan the whole node_modules hierarchy and create a FileObject instance for every single file? All our projects are really just plain HTML5 projects. The only reason why there's a "package.json" and "node_modules" folder in there, is because we use grunt to "build" (i.e. prepare for deployment) our projects. In the project properties, "Enable Node.js support" is unchecked as well, so why does NetBeans still insist on processing the whole "node_modules" folder? So what I'd like to see, is a way to tell NetBeans that it shouldn't parse/index the node_modules directory (of course, basic support like detecting whether or not all dependencies are installed should always be active). PS: this is very similar to issue 249908, which was about taking too long to open project because of adding a recursive listener to node_modules. Now it's, I assume, about taking too much memory to process a project because of creating a FileObject instance for every file in node_modules.
(In reply to terje7601 from comment #4) > Yes, I had opened about 25 HTML5 projects before leaving, so I assume > NetBeans hung while doing its background scanning on them. > > Of course, you could say: "no wonder it runs out of memory with that many > projects open". And I also still had the heap size at its default, so that > didn't help either. From this reason, I tend to close this issue as INVALID, sorry. > However, I think there's certainly room for improvement here. Why does > NetBeans apparently have to scan the whole node_modules hierarchy and create > a FileObject instance for every single file? Because they are underneath Site Root or Sources and therefore all these files are scanned and indexed by NetBeans. > All our projects are really just plain HTML5 projects. The only reason why > there's a "package.json" and "node_modules" folder in there, is because we > use grunt to "build" (i.e. prepare for deployment) our projects. In the > project properties, "Enable Node.js support" is unchecked as well, so why > does NetBeans still insist on processing the whole "node_modules" folder? Again, because these folders are visible in the Projects view - so they are scanned and indexed. NetBeans does not care that it is some special folder ("node_modules" in this case). Also, are you saying that npm modules are never used in plain HTML5 projects? > So what I'd like to see, is a way to tell NetBeans that it shouldn't > parse/index the node_modules directory (of course, basic support like > detecting whether or not all dependencies are installed should always be > active). If there is some folder that should not be "visible" for NetBeans, you can easily do it by changing your project structure, e.g.: <project> ├── node_modules ├── package.json └── www <-- make this folder your Site Root With this project structure, only files underneath www folder will be scanned and indexed by NetBeans - that is what you want to achieve, right? If you don't want/cannot change your project structure, feel free to use NBM file from issue #238709 to be able to ignore any folder in your project. Some comments in that issue can be helpful as well, I guess. > PS: this is very similar to issue 249908, which was about taking too long to > open project because of adding a recursive listener to node_modules. Now > it's, I assume, about taking too much memory to process a project because of > creating a FileObject instance for every file in node_modules. It is not, that issue is about slow attaching of listener and not about memory usage. Thanks for reporting.
This issue should be resolved as WONTFIX, of course. Thanks.