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 102229 [details] Thread dump taken after NetBeans had frozen for several minutes I came across this issue using NetBeans 6.9.1 on Red Hat 5. Judging by forum discussions and prior bug reports, this sort of behavior has been seen off and on for a year or two now... even if the underlying causes may not be the same (see 165862). Steps to reproduce: 1. Create a new "NetBeans Module" project. It makes no difference whether or not the project is Maven-based. 2. Right-click on the new project and select "New..." followed by "Action..." 3. On the first page of the New Action Wizard, it doesn't matter whether you select "Always Enabled" or "Conditionally Enabled". However, I did choose the former when generating the attached thread dump. 4. On the second page of the Wizard, wait until all of the pull-down menus have been fully populated. Then click on the "Category" pull-down menu at the top to change it's value. 5. Go to lunch, and kill the NetBeans process when you get back. You can still click the "Back" button, or cancel out of the Wizard altogether, UP UNTIL the moment you try to change one of those populated pull-down menus. At that point, the Wizard window freezes and you cannot take control of the underlying NetBeans window either. As mentioned in Step 3 above, I am attaching a thread dump of the application right before I killed it's process.
Pardon my inexperience (both with Bugzilla and with debugging NetBeans itself). Jesse Glick suggested elsewhere that the slowness detector output is helpful in diagnosing some freezes, but perhaps I misunderstand what the NetBeans slowness detector even is. My understanding is that it's something which appears in the bottom status bar when NetBeans is crawling. If so, then it is not being triggered in this case. NetBeans isn't crawling, it's just frozen outright... no slowness detector indicator appears.
(In reply to comment #1) > perhaps I misunderstand what the NetBeans > slowness detector even is. My understanding is that it's something which > appears in the bottom status bar when NetBeans is crawling. It appears after NB recovers from a UI freeze (i.e. 100% CPU situation, not a true deadlock). It is not possible to add an icon when the UI is frozen.
Sorry about the repeating comments earlier. The site's been a bit sluggish today (it took several hours to get the activation email when I first created my account)... and I presumably clicked the submit button a few times thinking it hadn't been received. At any rate, I tried this same operation on a Windows XP machine this evening when I returned home... and found that it works fine there. Oddly enough, the Red Hat Linux machine experiencing the problem is dramatically more powerful than the Windows machine (a low-end laptop).
Hello, Just to confirm, I've seen this bug on 6.9, 6.9.1 and, if I remember correctly, even on 6.8 (although the bug had fixed state on bugzilla). I also ran to this only on my linux machine (kubuntu, 32bit). I can attach thread dump or something if needed.
Created attachment 102325 [details] Thread dump of netbeans after action wizard window had frozen
Hello, I also have the same problem with netbeans 6.9.1 on Linux Ubuntu 10.04LTS. I attached a thread dump.
I can confirm this bug with NB 6.9.1 (with recent updates) on Ubuntu 10.10 maverick. I cannot use the Action Wizard at all, which is a show stopper for me (--> higher priority?!?) Some details: As soon as the Action Wizard dialog opens a lot of exceptions appear in $HOME/.netbeans/6.9/var/log/messages.log. The first one is: INFO [org.openide.filesystems.JarFileSystem]: error in opening zip file java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.jar.JarFile.<init>(JarFile.java:135) at java.util.jar.JarFile.<init>(JarFile.java:99) at org.openide.filesystems.JarFileSystem.getJar(JarFileSystem.java:952) at org.openide.filesystems.JarFileSystem.reOpenJarFile(JarFileSystem.java:732) at org.openide.filesystems.JarFileSystem.parse(JarFileSystem.java:835) at org.openide.filesystems.JarFileSystem.getCache(JarFileSystem.java:783) at org.openide.filesystems.JarFileSystem.children(JarFileSystem.java:443) at org.openide.filesystems.JarFileSystem$Impl.children(JarFileSystem.java:1009) at org.openide.filesystems.AbstractFileObject.list(AbstractFileObject.java:132) at org.openide.filesystems.AbstractFolder.getNewChildren(AbstractFolder.java:897) at org.openide.filesystems.AbstractFolder.refreshFolder(AbstractFolder.java:758) at org.openide.filesystems.AbstractFolder.refresh(AbstractFolder.java:939) at org.openide.filesystems.AbstractFileObject.refresh(AbstractFileObject.java:816) at org.openide.filesystems.AbstractFileObject.refresh(AbstractFileObject.java:798) at org.openide.filesystems.AbstractFolder.check(AbstractFolder.java:654) at org.openide.filesystems.AbstractFolder.getFileObject(AbstractFolder.java:469) at org.netbeans.api.java.classpath.ClassPath.findPath(ClassPath.java:940) at org.netbeans.api.java.classpath.ClassPath.findResourceImpl(ClassPath.java:954) at org.netbeans.api.java.classpath.ClassPath.findResource(ClassPath.java:409) at org.netbeans.modules.apisupport.project.layers.LayerUtils.currentify(LayerUtils.java:167) at org.netbeans.modules.apisupport.project.layers.BadgingSupport.annotateNameGeneral(BadgingSupport.java:190) at org.netbeans.modules.apisupport.project.layers.BadgingSupport.annotateNameSynch(BadgingSupport.java:165) at org.netbeans.modules.apisupport.project.ui.UIUtil$LayerItemPresenter.getFileObjectName(UIUtil.java:535) at org.netbeans.modules.apisupport.project.ui.UIUtil$LayerItemPresenter.computeDisplayName(UIUtil.java:550) at org.netbeans.modules.apisupport.project.ui.UIUtil$LayerItemPresenter.getDisplayName(UIUtil.java:511) at org.netbeans.modules.apisupport.project.ui.UIUtil$LayerItemPresenter.toString(UIUtil.java:518) at javax.swing.plaf.synth.SynthComboBoxUI$SynthComboBoxEditor.setItem(SynthComboBoxUI.java:488) at javax.swing.JComboBox.configureEditor(JComboBox.java:1383) at javax.swing.plaf.basic.BasicComboBoxUI.configureEditor(BasicComboBoxUI.java:769) at javax.swing.plaf.basic.BasicComboBoxUI.addEditor(BasicComboBoxUI.java:718) at javax.swing.plaf.basic.BasicComboBoxUI$Handler.propertyChange(BasicComboBoxUI.java:1668) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:339) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:276) at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:318) at java.awt.Component.firePropertyChange(Component.java:8152) at javax.swing.JComponent.firePropertyChange(JComponent.java:4440) at javax.swing.JComboBox.setEditable(JComboBox.java:382) at org.netbeans.modules.apisupport.project.ui.wizard.action.GUIRegistrationPanel.setEditable(GUIRegistrationPanel.java:131) at org.netbeans.modules.apisupport.project.ui.wizard.action.GUIRegistrationPanel.access$400(GUIRegistrationPanel.java:87) at org.netbeans.modules.apisupport.project.ui.wizard.action.GUIRegistrationPanel$2$1.run(GUIRegistrationPanel.java:325) 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:137) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:178) at java.awt.Dialog$1.run(Dialog.java:1046) at java.awt.Dialog$3.run(Dialog.java:1098) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Dialog.show(Dialog.java:1096) at org.netbeans.core.windows.services.NbPresenter.superShow(NbPresenter.java:1006) at org.netbeans.core.windows.services.NbPresenter.doShow(NbPresenter.java:1040) at org.netbeans.core.windows.services.NbPresenter.run(NbPresenter.java:1028) at org.netbeans.core.windows.services.NbPresenter.run(NbPresenter.java:121) at org.openide.util.Mutex.doEventAccess(Mutex.java:1361) at org.openide.util.Mutex.readAccess(Mutex.java:271) at org.netbeans.core.windows.services.NbPresenter.show(NbPresenter.java:1013) at java.awt.Component.show(Component.java:1563) at java.awt.Component.setVisible(Component.java:1515) at java.awt.Window.setVisible(Window.java:842) at java.awt.Dialog.setVisible(Dialog.java:986) at org.openide.loaders.TemplateWizard.instantiateImpl(TemplateWizard.java:498) at org.openide.loaders.TemplateWizard.instantiate(TemplateWizard.java:377) at org.netbeans.modules.project.ui.actions.NewFile.doPerform(NewFile.java:157) at org.netbeans.modules.project.ui.actions.NewFile.access$200(NewFile.java:83) at org.netbeans.modules.project.ui.actions.NewFile$PopupListener.actionPerformed(NewFile.java:336) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242) at javax.swing.AbstractButton.doClick(AbstractButton.java:357) at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1223) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1264) at java.awt.Component.processMouseEvent(Component.java:6267) at javax.swing.JComponent.processMouseEvent(JComponent.java:3267) at java.awt.Component.processEvent(Component.java:6032) at java.awt.Container.processEvent(Container.java:2041) at java.awt.Component.dispatchEventImpl(Component.java:4630) at java.awt.Container.dispatchEventImpl(Container.java:2099) at java.awt.Component.dispatchEvent(Component.java:4460) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168) at java.awt.Container.dispatchEventImpl(Container.java:2085) at java.awt.Window.dispatchEventImpl(Window.java:2478) at java.awt.Component.dispatchEvent(Component.java:4460) at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:137) 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) [catch] at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) WARNING [org.openide.filesystems.JarFileSystem]: cannot open /opt/netbeans-6.9.1/ide/modules/locale/org-netbeans-modules-jumpto_ja.jar This exception appears again and again for every other jar file below /opt/netbeans-6.9.1/*. The messages.log fills up quickly up to 8MB then rotates. Every jar missing exception appears multiple times. I got >10000 exceptions of this kind before I killed the NetBeans process. I verified that all of the jars actually exist and are readable for the current user (I grepped all jar filenames from the messages.log).
More details: I uninstalled NB 6.9.1, removed the $HOME/.netbeans folder, installed NB again and started with a new project from scratch. Didn't help, same error. I used File->New Project->Netbeans Modules->Module. Entered project name "Test", codebase "org.dm.test". In the "Projects" tab I invoked New->Action. That's all. The exceptions start to fill up in messages.log. As soon as I switch to the Next step in the Action wizard, cpu goes up to 100% and NB is unresponsive.
I tried to reproduce this bug on Windows 7 64bit. The Action Wizard works fine without any exceptions in messages.log. So I guess it is a Linux only issue!
(In reply to comment #9) > java.util.zip.ZipException: error in opening zip file > at java.util.zip.ZipFile.open(Native Method) > at java.util.zip.ZipFile.<init>(ZipFile.java:114) > at java.util.jar.JarFile.<init>(JarFile.java:135) > at java.util.jar.JarFile.<init>(JarFile.java:99) > at org.openide.filesystems.JarFileSystem.getJar(JarFileSystem.java:952) Probably a ulimit issue: http://wiki.netbeans.org/FaqOutOfFileDescriptors
(In reply to comment #12) > Probably a ulimit issue: http://wiki.netbeans.org/FaqOutOfFileDescriptors Yes, that's it!!! You saved my day! I watched the number of open file descriptors using the command given on the Wiki page and saw that the number quickly climbed up to 1023 and then stayed there. My ulimit is 1024. I increased the limit to 2048, logged out/in, restarted Netbeans and behold, the Action Wizard works again! I watched the number of open file descriptors again and now see that they climb up to max 1130. No more exceptions in message.log. Ubuntu's default of 1024 is perhaps a little bit too small, but I would be glad if this issue gets fixed. There's no need to open that many files at the same time when the Action Wizard scans all JARs, is it?!? Thanks a lot, Dirk.
I could not easily reproduce an increase in open file descriptors running the wizard in 6.9 & 7.0. Sometimes I got an extra ~230 descriptors. -J-Dorg.netbeans.modules.apisupport.project.layers.PlatformLayersCacheManager.level=FINE -J-Dorg.netbeans.core.projects.cache.level=FINE revealed that even after deleting $userdir/var/cache/nbplfsc the layer cache for ~7 clusters could be recreated without adding open descriptors. However the descriptor count did go up from double digits to ~300 after deleting all of $userdir/var/cache/, running the IDE with the project open, restarting the IDE, then opening the wizard - but not after restarting the wizard again. So this tells me that the descriptor count of ~300 is no leak at all, merely the IDE opening all the module JARs in the platform - which it needs to do during first startup (or startup after a module update), or when (re-)creating the layer cache for an NBM project. In other words, with 7 clusters installed in your IDE, you must be able to open >300 descriptors to run anything. With more optional features installed, you need more descriptors. This only turns into a performance issue if the ulimit is needlessly low. Based on comments from reporters, I am guessing that ulimit is indeed the problem in all these cases, rather than some unrelated issue. That is something that cannot be addressed in apisupport as such, but see bug #185135.