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 125932 [details] log files and snapshot in zip file netbeans-trunk-nightly-201210130002-windows.exe I am just editing two simple Java SE files, switching between them and copying a line, saving. Often the IDE becomes slow, stops responding for 5 seconds but then fine. I see entries in the log like: FileUtil.normalizeFile(C:\Documents and Settings\name\Application Data\NetBeans\dev) took 5,328 ms. ... FileUtil.normalizeFile(C:\Documents and Settings\name\Local Settings\Application Data\NetBeans\Cache\dev\index\s776\java\14) took 25,703 ms ... and more up to 66,969 ms Then the IDE takes 99% CPU and stops responding The IDE's memory counter is still updating, 280Mb out of 400Mb It is possible to take a snapshot but it takes an hour to save it. The IDE can be closed normally, but otherwise with 99% CPU it is not possible to work with it. This happened to me before with an earlier 7.3 build.
There is about 50 invocations of org.netbeans.core.windows.view.ui.popupswitcher.PopupSwitcher$2.run() 9.072538 9 220 ms (9,1%) 9 220 ms 53 I think it is the most suspicious thing. Then there is a lot of time spend in RP$SlowItem as it records the stack, but that has already been fixed in bug #192886. Passing to windowsystem to address the PopupSwitcher problem.
20 invocations of PopupSwitcher are expected during heavy document switching. The time the PopupSwitcher spends in EDT is in native method AccessController.getStackAccessControlContext() Perhaps #192886 isn't fixed properly.
It hung again yesterday while I saved a file that I had added a single line to, copied from another document. The hourglass cursor was showing and in the editor and the file was marked unsaved. After re-start, the file had the change.
Created attachment 126207 [details] Thread dump A thread dump. No snapshot this time because it takes so long to make.
Created attachment 126251 [details] a snapshot of a new instance of the problem
Created attachment 126284 [details] log file What I am seeing is quite strange. I am editing a couple of files. Other files are in editor tabs also but not touched for quite a while. Then I get a long pause of several seconds. I open the log to see what was going on. FileUtil.normalizeFile(SmsType.java) took 6,671 ms This is the file I am editing. So why please does the IDE have to do this? This is the file that I have been editing for hours on and off but never closed, so the IDE should have noticed a long time ago that this file does not have to be normalized. I read that this is an expensive operation. Also, why does the IDE stop me from writing code while doing this? C:\Documents and Settings\name\Application Data\NetBeans\dev\var\log\messages.log
This problem occurs when the popup is hidden while an instance of PopupSwitcher$2 (the Runnable in updateDescription) is in the event queue when the switcher is closed. This results in an infinite loop because lblDescription is never valid from that point forward.
(In reply to comment #7) > This problem occurs when the popup is hidden while an instance of > PopupSwitcher$2 (the Runnable in updateDescription) is in the event queue when > the switcher is closed. This results in an infinite loop because lblDescription > is never valid from that point forward. Thanks for the pointer. -> WS
core-main 5fa191b0424a
Integrated into 'main-golden', will be available in build *201210300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/5fa191b0424a User: S. Aubrecht <saubrecht@netbeans.org> Log: #220063 - don't update anything if the label isn't showing
*** Bug 221538 has been marked as a duplicate of this bug. ***
Will the fix for this will appear in the 7.2-series of Netbeans ?
(In reply to comment #12) > Will the fix for this will appear in the 7.2-series of Netbeans ? Marian, will there be another 7.2 patch?
(In reply to comment #13) > Marian, will there be another 7.2 patch? There is no plan to do so, but I'll mark it as candidate just in case ...