This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Created attachment 109186 [details] stack0 Product Version: NetBeans IDE 7.0.1 RC1 (Build cnd-build-5664-on-20110630) Java: 1.6.0_23; Java HotSpot(TM) 64-Bit Server VM 19.0-b09 System: Linux version 2.6.32-21-generic running on amd64; UTF-8; en_US (nb) -------------------------------------------------------------- * create Welcome * add vvv-qa as remote host * hyperlink (Ctrl+click) to iostream, then to ostream IDE freezes for 10-15 sec until a remote include is opened see also IZ199730
Created attachment 109187 [details] stack1
Created attachment 109188 [details] stack3
Created attachment 109189 [details] stack4
All stacks show GC activity in 8 threads. Provide more information about memory. If IDE is provided sufficient memory, take a memory snapshot.
I hope it helps /home/dn156283/Snapshots/Main-2011-07-01-1.snapshot
Editor team, could you, please, help to understand why there could be 10 sec delay? Threads are in CloneableEditor$DoInitialize.initDocument(CloneableEditor.java:681): "AWT-EventQueue-1" prio=10 tid=0x0000000041a05800 nid=0x417d in Object.wait() [0x00007f39fb6c3000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000f1631ec0> (a org.openide.text.CloneableEditor$DoInitialize) at java.lang.Object.wait(Object.java:485) at org.openide.text.CloneableEditor$DoInitialize.initDocument(CloneableEditor.java:681) - locked <0x00000000f1631ec0> (a org.openide.text.CloneableEditor$DoInitialize) at org.openide.text.CloneableEditor$DoInitialize.initVisual(CloneableEditor.java:719) at org.openide.text.CloneableEditor.getEditorPane(CloneableEditor.java:1232) at org.openide.text.CloneableEditorSupport.getOpenedPanes(CloneableEditorSupport.java:1132) at org.netbeans.modules.cnd.modelutil.CsmUtilities$3$PropertyChangeListenerImpl.run(CsmUtilities.java:818) 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:148) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) "org.openide.text Editor Initialization" daemon prio=10 tid=0x00000000417e5800 nid=0x4331 in Object.wait() [0x00007f39faebf000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x00000000f4e1cd10> (a org.openide.text.CloneableEditor$DoInitialize$1Query) at org.openide.text.CloneableEditor$DoInitialize$1Query.awaitAWT(CloneableEditor.java:451) - locked <0x00000000f4e1cd10> (a org.openide.text.CloneableEditor$DoInitialize$1Query) at org.openide.text.CloneableEditor$DoInitialize.initNonVisual(CloneableEditor.java:498) at org.openide.text.CloneableEditor$DoInitialize.run(CloneableEditor.java:332) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1424) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1968)
I am sorry but this is a question for Jarda who put there the 10s wait ...
My understanding is that the 10s is not a wait, its a timeout to recover from deadlock. What happens, IMO: 1. a file is being opened on background, that means the AWT is processing events 2. CsmUtilities$3$PropertyChangeListenerImpl.run as some time calls CloneableEditorSupport.getOpenedPanes, which needs to wait until the file is opened 3. in the background thread, a UserQuestionException occurs, so a dialog needs to be shown to the user. But, it is not possible to show the dialog because the AWT thread waits until getOpenedPanes finishes. Which needs to UQE to be resolved=>deadlock. 4. when the "emergency" 10s timeout passes, the UQE is unconditionally confirmed, so that the opening of the file may continue I do not know why CsmUtilities$3$PropertyChangeListenerImpl.run needs to call CloneableEditorSupport.getOpenedPanes, but it will most likely need to stop doing that and use something like NbDocument.findRecentEditorPane, which should not block. A side note: calling CloneableEditorSupport.getOpenedPanes is to my knowledge almost always wrong since the background file opening was implemented. I think it should have been deprecated and a big warning added to it when NbDocument.fREP was added.
Jan, thanks for the investigation. Probably you are right. Let's try to fix on our side
Other question: is it correct that PROP_OPENED_PANES is fired for async loaded editors before document is loaded? If user answers "No" to UQE => event shouldn't be fired, right?
Jan, thank you for investigation. BTW I just checked - CloneableEditorSupport.getOpenedPanes is not deprecated.
I have the same issue on local Ubuntu
I can see that on any remote project.
It happens when #include file is not in UTF-8, so question dialog should be opened, but awt is busy, so wait for 10 sec
fixed: http://hg.netbeans.org/cnd-main/rev/f915e4d5538a
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/f915e4d5538a User: Vladimir Voskresensky <vv159170@netbeans.org> Log: fixed #199820 - 10 sec freezing while hyperlink to non UTF-8 include files - use findRecentEditorPane method which does not hold AWT lock instead of getOpenedPanes
Fix is safe and fixes the issue.
Integrated into releases_elif: http://elif.russia.sun.com/hg/releases_elif/rev/6bb7e05fe609
verified in OSS build 30
Integrated into 'releases' Changeset: http://hg.netbeans.org/releases/rev/6bb7e05fe609 User: Vladimir Voskresensky <vv159170@netbeans.org> Log: fixed #199820 - 10 sec freezing while hyperlink to non UTF-8 include files - use findRecentEditorPane method which does not hold AWT lock instead of getOpenedPanes (transplanted from f915e4d5538a1816c5e748d1667d97d151a2365e)
verified in OSS dev build based on 7.0.1 patch2