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
jfinkel: Just editing a file.
java.lang.OutOfMemoryError: Java heap space
Created attachment 151801 [details]
One of the threads is repeating:
Local Variable: org.openide.filesystems.FileObject#173
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?
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
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)?
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)
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?
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).
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 http://www.webdrive.com/products/webdrive/.
In the heap dump there is a cycle among FileObjects.
See attached screenshot.
Created attachment 151832 [details]
Created attachment 151833 [details]
Attaching correct screenshot. :-)
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: http://bits.netbeans.org/download/trunk/nightly/latest/
Just as a test if the newly introduced FileObject.isSymbolikLink did not fixed the problem.
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, ...]
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2042)
It seems that some java.io.File 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.
> It seems that some java.io.File 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 java.io.File.listFiles() 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
- java.io.File.getCanonicalPath 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
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.
*** Bug 250302 has been marked as a duplicate of this bug. ***
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.