Typo in suggestion:
Suggestion: maybe for big files we SHOULD set persisted state to NONE ?

One could think that editing big files is stupid anyway.
However, in SQL files editing, it is frequent to manipulate very big files.
For example you can edit a file representing generated insert statements from a table to be replayed...

I tried to reproduce with 6MB text file (many times replicated small diff file) but cannot reproduce. I need more
details how to reproduce it. Is it possible that IDE reaches maximum heap size? In my case I have heap 88/129MB and
-Xmx365m.

Easy to reproduce. Steps to reproduce
- launch "C:\Program Files\NetBeans 6.1 RC2\bin\netbeans.exe" with no special memory flags
- open sample.sql size = 2 914 686 bytes
- quit Netbeans
- launch "C:\Program Files\NetBeans 6.1 RC2\bin\netbeans.exe" with no special memory flags
- progam hangs forever
- JDK = 1.6.0_05

Stack
"AWT-EventQueue-1" prio=6 tid=0x2b4e3800 nid=0x478 in Object.wait() [0x2c8bf000..0x2c8bfb94]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x03b4b048> (a org.openide.text.CloneableEditor$DoInitialize)
        at java.lang.Object.wait(Object.java:485)
        at org.openide.text.CloneableEditor$DoInitialize.initDocument(CloneableEditor.java:351)
        - locked <0x03b4b048> (a org.openide.text.CloneableEditor$DoInitialize)
        at org.openide.text.CloneableEditor$DoInitialize.initVisual(CloneableEditor.java:367)
        at org.openide.text.CloneableEditor$DoInitialize.run(CloneableEditor.java:246)
        at org.openide.text.CloneableEditor$DoInitialize.<init>(CloneableEditor.java:210)
        at org.openide.text.CloneableEditor.initialize(CloneableEditor.java:180)
        at org.openide.text.CloneableEditor.getEditorPane(CloneableEditor.java:809)
        at org.openide.text.CloneableEditorSupport.getOpenedPanes(CloneableEditorSupport.java:942)
        at org.netbeans.modules.debugger.jpda.projects.EditorContextImpl.getCurrentEditorCookie(EditorContextImpl.java:1885)
        - locked <0x05097f58> (a java.lang.Object)
        at org.netbeans.modules.debugger.jpda.projects.EditorContextImpl.getCurrentLineNumber_(EditorContextImpl.java:445)
        at org.netbeans.modules.debugger.jpda.projects.EditorContextImpl.getCurrentLineNumber(EditorContextImpl.java:426)
        at
org.netbeans.modules.debugger.jpda.projects.RunToCursorActionProvider.shouldBeEnabled(RunToCursorActionProvider.java:170)

        at
org.netbeans.modules.debugger.jpda.projects.RunToCursorActionProvider.access$100(RunToCursorActionProvider.java:86)
        at
org.netbeans.modules.debugger.jpda.projects.RunToCursorActionProvider$Listener.propertyChange(RunToCursorActionProvider.j
ava:217)
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339)
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276)
        at org.netbeans.core.windows.RegistryImpl.doFirePropertyChange(RegistryImpl.java:314)
        at org.netbeans.core.windows.RegistryImpl.topComponentOpened(RegistryImpl.java:183)
        - locked <0x05298240> (a org.netbeans.core.windows.RegistryImpl)
        at org.netbeans.core.windows.WindowManagerImpl.notifyRegistryTopComponentOpened(WindowManagerImpl.java:1007)
        at org.netbeans.core.windows.WindowManagerImpl.notifyTopComponentOpened(WindowManagerImpl.java:976)
        at org.netbeans.core.windows.Central.addModeOpenedTopComponent(Central.java:761)
        at org.netbeans.core.windows.ModeImpl.addOpenedTopComponent(ModeImpl.java:311)
        at org.netbeans.core.windows.PersistenceHandler.initModeFromConfig(PersistenceHandler.java:388)
        at org.netbeans.core.windows.PersistenceHandler.load(PersistenceHandler.java:205)
        at org.netbeans.core.windows.WindowSystemImpl.load(WindowSystemImpl.java:69)
        at org.netbeans.core.NonGui$2.run(NonGui.java:190)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
        at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:104)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

- only way out is to kill NB
- delete corresponding settings file
- restart

Created attachment 60618 [details]
big sql sample file

- see sql file attached
- REM: I don't think it is related to the handling of sql file as it happens for me and I have my own sql file handling
- true that it does not happen for text

seems as duplicate of issue 132386. Please, try to verify it with a trunk build. 

*** This issue has been marked as a duplicate of 132386 ***

Still happens. NPE on different line.

Confirmed. Variable prepareTask is null for some reason.

*** Issue 143856 has been marked as a duplicate of this issue. ***

See issue 144321. No longer an issue with large documents.

Samaresh I have no idea what is your comment about. This (#133236) is still valid issue. I am working on it.

*** Issue 144469 has been marked as a duplicate of this issue. ***

Fixed eefe8ba954b4.

It is fast fix to avoid hang. Problem is that CES.prepareDocument() returns null in this case. It is not correct and
should be fixed. But it is bigger change. I filed separate issue #144722 for this.

Integrated into 'main-golden', available in build *200808220201* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/eefe8ba954b4
User: Marek Slama <mslama@netbeans.org>
Log: #133236: Handle null task returned from CES.prepareDocument().

*** Issue 145431 has been marked as a duplicate of this issue. ***