Created attachment 114831 [details]
stacktrace

I'm hit by the same issue, also on a Netbeans PHP project, also on Win7 x64 with Java 1.7.0 64 bit. I can kill Netbeans and the underlying Java processes and after restarting, the scanning does not hang at the same point ... sometimes hangs at 100%, sometimes at 66%, etc.

Curiously, a few days ago the same project opened fine.

Anyone knows a workaround?

OK, the workaround that I found is:

- edit <Netbeans>/bin/etc/netbeans.conf and change the netbeans_jdkhome= value to point to some directory that does *not* exist. 
- start Netbeans, it will complain the JRE was not found and will propose to use the default version
- Answer "yes" and you should be in business

That worked for me every time.

p.s. As a test, I installed JRE 1.7u2 x86 and changed netbeans_jdkhome= to use that instead of the x64 version, but Netbeans still hangs. This time it opens but hangs when the status line read "opening main window", which is before "scanning projects".

Don't work for me.
If i change netbeans_jdkhome= with nonexistent directory i've only
 ./netbeans-7.1/bin/netbeans
Cannot find java. Please use the --jdkhome switch.

7.0.1 work fine, the problem is only in 7.1

(In reply to comment #4)
> Don't work for me.
> If i change netbeans_jdkhome= with nonexistent directory i've only
>  ./netbeans-7.1/bin/netbeans
> Cannot find java. Please use the --jdkhome switch.
> 
> 7.0.1 work fine, the problem is only in 7.1

Are you talking about NB under Linux? My workaround is working under Win 7 x64.

I never tried NB under Linux but it looks like under Windows, NB comes with a bundled version of Java and hence the above workaround works.

I doubt that setting wrong JDK folder helps.
There was a problem  with sym link cycles (adding file listener hanged in the cycle) it's fixed in 7.2 dev builds.
If someone has the hang which is not caused by sym link please attach several successive thread dumps with 5 sec pause. If you have sym links try to use dev builds.

Don't work for me:
SEVERE [global]
java.lang.OutOfMemoryError: Java heap space
        at java.awt.image.DataBufferInt.<init>(DataBufferInt.java:75)
        at java.awt.image.Raster.createPackedRaster(Raster.java:470)
        at java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1032)
        at java.awt.GraphicsConfiguration.createCompatibleImage(GraphicsConfiguration.java:149)
        at java.awt.GraphicsConfiguration.createCompatibleImage(GraphicsConfiguration.java:178)
        at sun.awt.image.SunVolatileImage.getBackupImage(SunVolatileImage.java:236)
        at sun.awt.image.VolatileSurfaceManager.getBackupSurface(VolatileSurfaceManager.java:263)
        at sun.awt.image.VolatileSurfaceManager.initialize(VolatileSurfaceManager.java:126)
        at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:88)
        at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:117)
        at java.awt.GraphicsConfiguration.createCompatibleVolatileImage(GraphicsConfiguration.java:307)
        at java.awt.GraphicsConfiguration.createCompatibleVolatileImage(GraphicsConfiguration.java:208)
        at javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:988)
        at javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1398)
        at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:311)
        at javax.swing.RepaintManager.paint(RepaintManager.java:1206)
        at javax.swing.JComponent.paint(JComponent.java:1040)
        at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
        at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:78)
        at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:115)
        at java.awt.Container.paint(Container.java:1967)
        at java.awt.Window.paint(Window.java:3867)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:781)
        at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:728)
        at javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:677)
        at javax.swing.RepaintManager.access$700(RepaintManager.java:59)
        at javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1621)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
        at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:705)
        at java.awt.EventQueue.access$000(EventQueue.java:101)
        at java.awt.EventQueue$3.run(EventQueue.java:666)
[catch] at java.awt.EventQueue$3.run(EventQueue.java:664)
WARNING [org.netbeans.core.TimableEventQueue]: no snapshot taken
INFO [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: Indexing of: /pagine/piumi.new took: 267188 ms (New or modified files: 0, Deleted files: 0) [Adding listeners took: 226 ms]

There isn't symbolyc or hard link in this project.
Version:
netbeans-trunk-nightly-201202060400-ml-php-linux

Linux slack-current 32 bit, 4 gb ram
Linux version 3.1.6-smp (root@roberto) (gcc version 4.5.3 (GCC) ) #2 SMP Wed Dec 28 16:45:57 CET 2011

I have no symlinks or hardlinks either, but I'm not sure you were referring to *nix systems (I'm on Win 7 x64).

My workaround (changing netbeans_jdkhome in conf) worked every time when NB was hanging with the jdkhome set to a system wide JRE path. I'm not sure whether I was just lucky or not ...

However, I reverted the jdkhome setting back to the JRE 7u2 so that I can do a thread dump and post here but now it works again ... isn't it possible this bug is caused by soething else?

In such a case can you generate the successive thread dumps when IDE freezes? We need them to see where the IDE is frozen.
We need at least 3 thread dumps with 5 sec delay.
Here is a description how to generate thread dumps: http://wiki.netbeans.org/GenerateThreadDump
Thanks

Created attachment 115735 [details]
first dump

Created attachment 115736 [details]
Second dump

Created attachment 115737 [details]
third dump

robyt - please, do your project(s) contain some large files ? e.g. some PHP library documentation, or some machine-generated parsed (e.g. html, xml, ...) files that reside in project folder 

?

(In reply to comment #13)
> robyt - please, do your project(s) contain some large files ? e.g. some PHP
> library documentation, or some machine-generated parsed (e.g. html, xml, ...)
> files that reside in project folder 
> 
> ?

i've some big directory (~500mb) but with many jpeg files, php or js is a little part (few mb)

Thanks for reply.
Seems as duplicate of #207991.
The new CSS parser causes OOM by very big number of tokens.

*** This bug has been marked as a duplicate of bug 207991 ***

Not sure about the other cases for which we don't have the stack traces.
Anyone else in this issue having the hang during scan please attach the stack traces.

Tomas, what kind of stack traces do you need? 
I see this issue in my env in dev build.

Created attachment 115951 [details]
threads dump

Vladimir,
it does not seem to have something in common with scanning. At least according to thread dump. There is no RepositoryUpdater active at all.
It seems as a deadlock among the cnd MakeConfigurationDescriptor and projects.ui configurations.

*** This bug has been marked as a duplicate of bug 207991 ***

The "Folder Instance Processor" thread is blocked by:
MakeConfigurationDescriptor.waitInitTask()
while holding monitors on following objects:
0xcbff1320
0xcc65f118
0xb4bc0d98

The EDT is waiting on:
0xcc65f118

And the "Reading project configuraion" which the "Folder Instance Processor" seems to wait for
is blocked to wait for EDT
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0xcc1e3930> (a org.netbeans.core.windows.services.DialogDisplayerImpl$1AWTQuery)
        at java.lang.Object.wait(Object.java:485)
        at org.netbeans.core.windows.services.DialogDisplayerImpl.notify(DialogDisplayerImpl.java:280)
        - locked <0xcc1e3930> (a org.netbeans.core.windows.services.DialogDisplayerImpl$1AWTQuery)

Tomas, I'm sorry, attached wrong file (my dev ide does not have cnd enabled). Please, try correct one for analysis.

Created attachment 115954 [details]
java ide threads dump

The Vladimir dump is caused by a bug in a new source prefetching.
I've created a new issue report to keep it separated from this 7.1 problems.
The new issue number is 208663 (http://netbeans.org/bugzilla/show_bug.cgi?id=208663)
Returning this one to original OOM.

*** This bug has been marked as a duplicate of bug 207991 ***