Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 250194 - OutOfMemoryError: Java heap space
OutOfMemoryError: Java heap space
Product: platform
Classification: Unclassified
Component: Filesystems
All All
: P3 (vote)
Assigned To: Jaroslav Havlin
: 250302 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2015-02-03 23:10 UTC by jfinkel
Modified: 2015-02-13 15:01 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT

stacktrace (602 bytes, text/plain)
2015-02-03 23:10 UTC, jfinkel
Screenshot (59.11 KB, image/png)
2015-02-05 15:34 UTC, Tomas Zezula
Screenshot (87.68 KB, image/png)
2015-02-05 15:38 UTC, Tomas Zezula

Note You need to log in before you can comment on or make changes to this bug.
Description jfinkel 2015-02-03 23:10:24 UTC
Build: NetBeans IDE 7.4 (Build 201310111528)
VM: Java HotSpot(TM) 64-Bit Server VM, 25.0-b70, Java(TM) SE Runtime Environment, 1.8.0-b132
OS: Windows 8

User Comments:
jfinkel: Just editing a file.

java.lang.OutOfMemoryError: Java heap space
   at org.netbeans.modules.diff.builtin.provider.HuntDiff.diff(
   at org.netbeans.modules.diff.builtin.provider.BuiltInDiffProvider.computeDiff(
   at org.netbeans.modules.versioning.ui.diff.DiffSidebar$RefreshDiffTask.computeDiff(
   at org.netbeans.modules.versioning.ui.diff.DiffSidebar$
   at org.openide.util.RequestProcessor$
   at org.openide.util.RequestProcessor$
Comment 1 jfinkel 2015-02-03 23:10:26 UTC
Created attachment 151801 [details]
Comment 2 Ondrej Vrabec 2015-02-04 08:32:58 UTC
One of the threads is repeating:
at org.netbeans.modules.parsing.impl.indexing.FileObjectCrawler.collect(
       Local Variable: org.openide.filesystems.FileObject[]#173
    at org.netbeans.modules.parsing.impl.indexing.FileObjectCrawler.collect(
       Local Variable: org.openide.filesystems.FileObject[]#174

over and over, there seems to be a cyclic symlink in user's workspace.

"N:\public_html\moderatemeans" seems to contain a symlink pointing to itself.

to reporter: can you please check the folder and remove the cyclic symlink if there is one?
Comment 3 jfinkel 2015-02-04 14:26:04 UTC
There is a symlink pointing to a subdirectory of the same name, not to itself.  

That is, public_html/a/b/c -> public_html/a/b/b
Comment 4 Tomas Zezula 2015-02-05 12:10:39 UTC
There is a detection of symbolic links which works fine on UNIX (links created by the ln -s). Needed to be tested on Windows.
Please how you created the link, by mkling?

>That is, public_html/a/b/c -> public_html/a/b/b
Do I understand correctly that c is linked to b (parent folder)?

Comment 5 jfinkel 2015-02-05 14:14:11 UTC
c is a symlink pointing to a SIBLING folder that just happens to have the same name as its PARENT.

      orange -> colors (i.e., home/colors/colors)
Comment 6 Tomas Zezula 2015-02-05 14:21:44 UTC
So there is no cycle while traversing the file system. Right?
It should not end in the loop even when the detection of cycles does not work on Windows (we are using java.nio.file.Files.isSymbolicLink for symlink detection).

Unfortunately I cannot verify as I don't have Windows.
To jiriprox: Jirko, can you verify such a project layout on Windows?
Comment 7 jfinkel 2015-02-05 14:28:15 UTC
I suppose I should mention that the files are being accessed through WebDrive, which is a Windows SFTP client that I use to mount the remote network drive as a local drive.

I know for a fact that there is a bug in their driver that consistently causes my Windows machine to BSOD if, and only if, I am accessing the files with NetBeans 8.  I have sent them numerous memory dumps and they cannot figure out what is happening.  This is why I am still stuck on NetBeans 7.4.  At least it does not cause a BSOD, whereas using NetBeans 8.0 to access WebDrive-mounted folders will ALWAYS result in a BSOD within 10 hours (sometimes 8 minutes, sometime 8 hours).
Comment 8 Tomas Zezula 2015-02-05 14:35:00 UTC
I doubt that if there is a cycle in the folders the java.nio.file.Files.isSymbolicLink can detect it as it works correctly only on local file system.
I will ask Jirka to test isSymbolicLink on Windows + WebDrive
Comment 9 Tomas Zezula 2015-02-05 15:33:51 UTC
In the heap dump  there is a cycle among FileObjects.
See attached screenshot.
Comment 10 Tomas Zezula 2015-02-05 15:34:26 UTC
Created attachment 151832 [details]
Comment 11 Tomas Zezula 2015-02-05 15:38:15 UTC
Created attachment 151833 [details]

Attaching correct screenshot. :-)
Comment 12 Tomas Zezula 2015-02-05 15:41:59 UTC
However the Files.isSymbolicLink returns false.
To reporter NB 7.4 is quite old release can you try to reproduce the problem with a dev build:
Just as a test if the newly introduced FileObject.isSymbolikLink did not fixed the problem.
Comment 13 Jaroslav Havlin 2015-02-06 15:22:16 UTC
java.lang.IllegalArgumentException: All children must have the same parent: N:/public_html vs. N:/public_html/moderatemeans
Children: [N:\public_html\moderatemeans@5d6b8a91:5bb14f55, N:\public_html\moderatemeans\nbproject@aa0ca498:5843d6e, ...]
	at org.openide.filesystems.Ordering.getOrder(
	at org.openide.filesystems.FileUtil.getOrder(
	at org.openide.loaders.FolderChildren$1R.getPositionedFolderChildrenPairs(
	at org.openide.loaders.FolderChildren$
	at org.openide.util.RequestProcessor$
[catch] at org.openide.util.RequestProcessor$

It seems that some f.listFiles() returns an array that contains f.
Might be caused by some bug in WebDrive.

I'll try to reproduce it when I switch to Windows.

Thank you.
Comment 14 Jaroslav Havlin 2015-02-13 11:11:53 UTC
> It seems that some f.listFiles() returns an array that
> contains f.
I cannot confirm this theory. I created folder structure described in comment 3
(public_html/a/b/c -> public_html/a/b/b), and returned
correct array of children for public_html/a and its subdirectories.

Checked with WebDrive version 12.1 build #4082 64 bit.

I've tested behavior of the directory mounted by WebDrive, with these results:

 - java.nio.file.Files.isSymbolicLink() returns false for public_html/a/b/c,
   which is incorrect
 - return "public_html/a/b/c" (identical value)
   for "public_html/a/b/c", which is probably correct, as getCanonicalPath()
   does not resolve symbolic links on Windows.
 - If new file is created in "public_html/a/b/c", it is not shown in
   "public_html/a/b/b" (and vice versa) in native file manager
   (e.g. Windows Explorer). The files are created on the server, the mounted
   directories are just not updated. Invoking "Sync Now" in WebDrive Manager
   does not help. I have to disconnect and connect (mount) again to update
   content of the folders.
 - When I created a recursive symlink on the server, reconnected the WebDrive
   and invoked "Check for External Changes" in NetBeans, a lot of NetBeans
   exception dialogs and WebDrive errors appeared, followed by Windows BSOD.
   (Very nice, I had to write this long comment twice. But I admit I should
   have expected it :-).)

I think the conclusion is:
 - WebDrive probably doesn't try to handle symbolic links and it contains some
   critical bug that makes the system crash when recursive symlink (or maybe
   just very long path) is encountered.
 - The reporter's project seems to contain a recursive symlink.
 - There is no way to detect symlinks in WebDrive mounted directories.
   (Well, we may detect long paths, but they are legal, so what should be
   the limit?).

Reporter, have you considered using some of version control systems for your 
project instead of mounting remote directory? They are well supported in
NetBeans IDE and highly recommended.

I don't think we should workaround an obvious bug in minor third-party software
in the IDE (anyway, the fix would be complicated and risky, if possible at all),
so I'm closing this issue as WONTFIX.

Thank you for reporting, jfinkel, and for understanding.
Comment 15 Jaroslav Havlin 2015-02-13 11:20:18 UTC
*** Bug 250302 has been marked as a duplicate of this bug. ***
Comment 16 jfinkel 2015-02-13 15:01:21 UTC
I want to thank you all very much for investigating this.  It confirms what I have been telling the WebDrive folks for over a year: there is a bug in their driver.

As far as I know, our file structure DOES NOT contain recursive symlinks.  If it appears otherwise, then I assume that is due to a bug in WebDrive.

I have moved to using NetBeans' built in SFTP functionality; but I have yet to be able to figure out how to integrate that with Subversion.  But that is a different issue.

Thanks again.  I have passed along the results of your investigation to the WebDrive devos.

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