Created attachment 127819 [details]
stacktrace

Exactly the same symptoms as occurred for me in 

http://netbeans.org/bugzilla/show_bug.cgi?id=221772

NB scans, chews up all the memory with no scanning progress, then starts to GC thrash, then hits an OutOfMemoryError.

Please provide a heap dump.
I do not think, that this is caused by some memory problem in uihandler, output to a GZIPOutputStream should not require an excessive amount of memory. I think that something else consumes memory and GZIPOutputStream simply did not have enough space.

Please provide a heap dump http://wiki.netbeans.org/FaqMemoryDump

I'm sorry, the heap dump is there http://statistics.netbeans.org/exceptions/exception.do?id=629229 I didn't notice it.
It's truncated, but it looks like the problem is in PHP, several large char arrays are held by PHP.

Another dump http://statistics.netbeans.org/analytics/exception.do?id=630557

Ondro, I guess that these arrays are in the editor - can you evaluate please? If not, please reassign back to me.

Thanks a lot.

Sorry, but I'm not able to ungzip any of heapdumps :( I can download them, but it's somehow corrupted. Nevertheless, if there is some issue with big char arrays in PHP parser, I made some improvements, but it _always_ will be erroneous to parse a really big files and I can't do anything with that :/

It looks like there is a loop in  F:\xmod . See messages.log attached to exception report.

As Tomas wrote, it seems that there is a loop in mounted F:\xmod. It's really not a good idea to do that. Maybe tmysik will add something ;)

Do you mean a symlink loop?

In that case yes there probably is.

f:\xmod\* is a bunch of composer modules. Some modules depend on other modules.

So for example when developing f:\xmod\xmod-cms the vendor directory would have a link f:\xmod\xmod-cms\vendor\xmod\common -> f:\xmod\xmod-common

Should NB just resolve each path to its absolute canonical path before scanning? Not only to avoid symlink loops, but also as it should be faster.

Also on a side note, does NB hash a file before it scans it? No point scanning an identical file twice.

Also "but it _always_ will be erroneous to parse a really big files"

That fair enough if NB can't parse big files, but could you make NB tell the users  if a file is too big? Or make a setting with like "max file size to scan"?

The cause here seems to be a loop on your FS (see comment #8) - I doubt that we can do anything with it. In any case, reassigning to parsing - could you please answer questions from comments #10 and #11?

Thanks.

You want me to reply to my own questions? Or are you talking to some one else?

And like I said in comment 10, NB should avoid symlink loops by looking up the absolute canonical path (i.e. in PHP you would `realpath($file)` the file first)

(In reply to comment #13)
> You want me to reply to my own questions?

No :)

> Or are you talking to some one else?

Yes, to the owner of the parsing component (I reassigned this issue there).

In fact the parsing.api resolves the path to the canonical ones to detect cycles and prevents them.
It seems that java.io.File.getCanonicalFile() does not work on Windows. The F: is a network drive exported from UNIX or NT junctions are used to simulate symlinks? 
Cycle in FS on Windows is not a good idea.

F:\ is just a standard NTFS partition on a normal hard drive.

The symlinks are made using `mklink /D target source`

I have never had any other problem with other software and these symlinks. 

I ran a quick test in Java

F:\> mkdir link-target
F:\> mklink /D link f:\link-target
symbolic link created for link <<===>> f:\link-target 

public static void main(String[] args) throws IOException {
    File file = new File("f:\\link");
    System.out.println(file);
    System.out.println(file.getCanonicalFile());
    System.out.println(file.getCanonicalFile().getCanonicalFile());
}

f:\link
F:\link
F:\link

So it does seem like it might be a Java problem.

Looking it up I don't see an easy way around it with out using java.nio in Java 1.7

http://docs.oracle.com/javase/tutorial/essential/io/links.html
http://stackoverflow.com/questions/813710/java-1-6-determine-symbolic-links

>So it does seem like it might be a Java problem.
Yes, this is what I've written in comment #15 and why I've assigned it to JDK Problems category.
I have an idea (rather workaround) but can be tried.
As you correctly pointed out we cannot link to JDK 7 as NB has to run at least on 2 newest JDKs,
however we we can use reflection to invoke it when IDE is running on JDK 7.

As I don't have Windows I need you to test if Files.isSymbolicLink() works fine for mklink and also measure at least a bit a performance of the IO call. Done by simple test below.

Here is the code:


import java.io.File;
import java.nio.file.FileSystem;
import java.nio.file.Files;
import java.nio.file.Path;

class Test {
    public static void main(String[] args) {
        final File f = new File ("f:\\link");
        long st = System.nanoTime();
        boolean res = false;
        for (int i=0; i<100_000; i++){
            Path p = f.toPath();
            res = Files.isSymbolicLink(p);
        }
        long et = System.nanoTime();
        System.out.println(String.format(
            "file: %s, is symlink: %b, time of 100,000 invocations: %d ms",
            f,
            res,
            (et-st)/1000000));
    }
}

(In reply to comment #18)

> As I don't have Windows I need you to test if Files.isSymbolicLink() works fine
> for mklink and also measure at least a bit a performance of the IO call. Done
> by simple test below.

I ran that test using:

java version "1.7.0_10-ea"
Java(TM) SE Runtime Environment (build 1.7.0_10-ea-b11)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

The result is:

file: d:\link, is symlink: true, time of 100,000 invocations: 6500 ms

JDK team suggests this workaround: file.toPath().toRealPath()

Why is this set to wont fix?

(In reply to comment #21)
> Why is this set to wont fix?

Because it is a bug in JDK implementation.

So I am not allowed to use Netbeans?

(In reply to comment #23)
> So I am not allowed to use Netbeans?

Either wait till the bug is fixed in new JDK release or don't use symbolic links.
You can also open a new issue against Parsing and Indexing module to try some workaround.

*** Bug 222087 has been marked as a duplicate of this bug. ***