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.
When I try to use Ruby Gems, sometimes NetBeans becomes deadlock. I heard, this is because thread problem of Ruby. My environment is following: OS: Ubuntu 7.10 Java: JD1.6.0_03 NetBeans:6.0 rc1 I attach jstack thread dump of this issue. 2007-11-03 22:40:37 Full thread dump Java HotSpot(TM) Client VM (1.6.0_03-b05 mixed mode, sharing): "Attach Listener" daemon prio=10 tid=0x08590400 nid=0x4014 runnable [0x00000000..0x00000000] java.lang.Thread.State: RUNNABLE "Default RequestProcessor" daemon prio=10 tid=0x08594400 nid=0x3fb6 waiting for monitor entry [0xb4694000..0xb4695040] java.lang.Thread.State: BLOCKED (on object monitor) at java.awt.Container.clearCurrentFocusCycleRootOnHide(Container.java:3124) - waiting to lock <0x7e2d1218> (a java.awt.Component$AWTTreeLock) at java.awt.Component.hide(Component.java:1446) at java.awt.Component.show(Component.java:1421) at java.awt.Component.setVisible(Component.java:1372) at javax.swing.JComponent.setVisible(JComponent.java:2610) at org.netbeans.modules.ruby.rubyproject.gems.GemPanel.updateGems(GemPanel.java:200) - locked <0x80b67ce8> (a org.netbeans.modules.ruby.rubyproject.gems.GemPanel) at org.netbeans.modules.ruby.rubyproject.gems.GemPanel.access$3100(GemPanel.java:83) at org.netbeans.modules.ruby.rubyproject.gems.GemPanel$3.run(GemPanel.java:936) - locked <0x7daa0000> (a org.netbeans.modules.ruby.rubyproject.gems.GemPanel$3) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) "pool-3-thread-1" prio=10 tid=0x0887d400 nid=0x3eca waiting on condition [0xb00d0000..0xb00d10c0] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x7eaeb668> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1925) at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:358) at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:946) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:906) at java.lang.Thread.run(Thread.java:619) "GSF Source Worker Thread" prio=10 tid=0x088b2000 nid=0x3eaf waiting on condition [0xb144e000..0xb144efc0] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x7e851c38> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:1963) at java.util.concurrent.PriorityBlockingQueue.poll(PriorityBlockingQueue.java:245) at org.netbeans.napi.gsfret.source.Source$CompilationJob.run(Source.java:1126) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) "org.netbeans.modules.gsfret.source.usages.RepositoryUpdater" prio=10 tid=0x088b6000 nid=0x3eae in Object.wait() [0xb164f000..0xb1650040] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x7e851d78> (a java.util.TaskQueue) at java.lang.Object.wait(Object.java:485) at java.util.TimerThread.mainLoop(Timer.java:483) - locked <0x7e851d78> (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:462) "DestroyJavaVM" prio=10 tid=0x08059c00 nid=0x3e93 waiting on condition [0x00000000..0xb7d63090] java.lang.Thread.State: RUNNABLE "AWT-EventQueue-1" prio=10 tid=0x08317400 nid=0x3eab waiting for monitor entry [0xb37d8000..0xb37d9dc0] java.lang.Thread.State: BLOCKED (on object monitor) at java.awt.Component.getName(Component.java:787) - waiting to lock <0x80b67ce8> (a org.netbeans.modules.ruby.rubyproject.gems.GemPanel) at com.sun.java.swing.plaf.gtk.GTKStyle.getColor(GTKStyle.java:176) at javax.swing.plaf.synth.SynthLookAndFeel.paintRegion(SynthLookAndFeel.java:367) at javax.swing.plaf.synth.SynthLookAndFeel.update(SynthLookAndFeel.java:331) at javax.swing.plaf.synth.SynthPanelUI.update(SynthPanelUI.java:94) at javax.swing.JComponent.paintComponent(JComponent.java:763) at javax.swing.JComponent.paint(JComponent.java:1027) at javax.swing.JComponent.paintChildren(JComponent.java:864) - locked <0x7e2d1218> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:1036) at javax.swing.JComponent.paintChildren(JComponent.java:864) - locked <0x7e2d1218> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:1036) at javax.swing.JLayeredPane.paint(JLayeredPane.java:564) at javax.swing.JComponent.paintChildren(JComponent.java:864) - locked <0x7e2d1218> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5129) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:285) at javax.swing.RepaintManager.paint(RepaintManager.java:1128) at javax.swing.JComponent.paint(JComponent.java:1013) at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:21) at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:60) at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:97) at java.awt.Container.paint(Container.java:1797) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:734) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679) at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659) at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:177) at java.awt.Dialog$1.run(Dialog.java:1039) at java.awt.Dialog$3.run(Dialog.java:1091) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Dialog.show(Dialog.java:1089) at org.netbeans.core.windows.services.NbPresenter.superShow(NbPresenter.java:834) at org.netbeans.core.windows.services.NbPresenter.doShow(NbPresenter.java:868) at org.netbeans.core.windows.services.NbPresenter.run(NbPresenter.java:856) at org.netbeans.core.windows.services.NbPresenter.run(NbPresenter.java:104) at org.openide.util.Mutex.doEventAccess(Mutex.java:1223) at org.openide.util.Mutex.readAccess(Mutex.java:242) at org.netbeans.core.windows.services.NbPresenter.show(NbPresenter.java:841) at java.awt.Component.show(Component.java:1419) at java.awt.Component.setVisible(Component.java:1372) at java.awt.Window.setVisible(Window.java:801) at java.awt.Dialog.setVisible(Dialog.java:979) at org.netbeans.modules.ruby.rubyproject.gems.GemAction.showGemManager(GemAction.java:88) at org.netbeans.modules.ruby.rubyproject.gems.GemAction.performAction(GemAction.java:56) at org.openide.util.actions.CallableSystemAction$1.run(CallableSystemAction.java:118) at org.netbeans.modules.openide.util.ActionsBridge.doPerformAction(ActionsBridge.java:77) at org.openide.util.actions.CallableSystemAction.actionPerformed(CallableSystemAction.java:114) 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:1216) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257) at java.awt.Component.processMouseEvent(Component.java:6038) at javax.swing.JComponent.processMouseEvent(JComponent.java:3265) at java.awt.Component.processEvent(Component.java:5803) at java.awt.Container.processEvent(Container.java:2058) at java.awt.Component.dispatchEventImpl(Component.java:4410) at java.awt.Container.dispatchEventImpl(Container.java:2116) at java.awt.Component.dispatchEvent(Component.java:4240) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916) at java.awt.Container.dispatchEventImpl(Container.java:2102) at java.awt.Window.dispatchEventImpl(Window.java:2429) at java.awt.Component.dispatchEvent(Component.java:4240) at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) 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) "Thread-2" daemon prio=10 tid=0x08689c00 nid=0x3eaa in Object.wait() [0xb2196000..0xb2196e40] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x7e5bec38> (a java.util.LinkedList) at java.lang.Object.wait(Object.java:485) at java.util.prefs.AbstractPreferences$EventDispatchThread.run(AbstractPreferences.java:1461) - locked <0x7e5bec38> (a java.util.LinkedList) "TimerQueue" daemon prio=10 tid=0x083a2c00 nid=0x3ea4 in Object.wait() [0xb35d8000..0xb35d9040] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at javax.swing.TimerQueue.run(TimerQueue.java:236) - locked <0x7e316638> (a javax.swing.TimerQueue) at java.lang.Thread.run(Thread.java:619) "AWT-Shutdown" prio=10 tid=0x08316400 nid=0x3ea2 in Object.wait() [0xb39da000..0xb39daf40] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259) - locked <0x7e2cbf90> (a java.lang.Object) at java.lang.Thread.run(Thread.java:619) "AWT-XAWT" daemon prio=10 tid=0x08315c00 nid=0x3ea1 runnable [0xb3bdb000..0xb3bdbdc0] java.lang.Thread.State: RUNNABLE at sun.awt.X11.XToolkit.waitForEvents(Native Method) at sun.awt.X11.XToolkit.run(XToolkit.java:544) at sun.awt.X11.XToolkit.run(XToolkit.java:519) at java.lang.Thread.run(Thread.java:619) "Java2D Disposer" daemon prio=10 tid=0x082d5000 nid=0x3ea0 in Object.wait() [0xb3f35000..0xb3f35e40] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x7e2cc028> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at sun.java2d.Disposer.run(Disposer.java:125) at java.lang.Thread.run(Thread.java:619) "Timer-0" daemon prio=10 tid=0x082bcc00 nid=0x3e9d in Object.wait() [0xb4895000..0xb4895fc0] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.util.TimerThread.mainLoop(Timer.java:509) - locked <0x7e25fdc8> (a java.util.TaskQueue) at java.util.TimerThread.run(Timer.java:462) "CLI Requests Server" daemon prio=10 tid=0x08292400 nid=0x3e9c runnable [0xb4a96000..0xb4a97040] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked <0x7e25fe70> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.netbeans.CLIHandler$Server.run(CLIHandler.java:1003) "Active Reference Queue Daemon" daemon prio=10 tid=0x08290000 nid=0x3e9b in Object.wait() [0xb4d0e000..0xb4d0eec0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x7e260000> (a java.lang.ref.ReferenceQueue$Lock) at org.openide.util.Utilities$ActiveQueue.run(Utilities.java:3056) at java.lang.Thread.run(Thread.java:619) "Low Memory Detector" daemon prio=10 tid=0x0808e800 nid=0x3e99 runnable [0x00000000..0x00000000] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=10 tid=0x0808d000 nid=0x3e98 waiting on condition [0x00000000..0xb51cf8d8] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x0808bc00 nid=0x3e97 runnable [0x00000000..0xb53d0da0] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=10 tid=0x08082c00 nid=0x3e96 in Object.wait() [0xb565a000..0xb565a140] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x7e2601e8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x08081c00 nid=0x3e95 in Object.wait() [0xb585a000..0xb585afc0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x7e25fc08> (a java.lang.ref.Reference$Lock) "VM Thread" prio=10 tid=0x08080400 nid=0x3e94 runnable "VM Periodic Task Thread" prio=10 tid=0x08090000 nid=0x3e9a waiting on condition JNI global references: 1795 Found one Java-level deadlock: ============================= "Default RequestProcessor": waiting to lock monitor 0x08086eac (object 0x7e2d1218, a java.awt.Component$AWTTreeLock), which is held by "AWT-EventQueue-1" "AWT-EventQueue-1": waiting to lock monitor 0xadeed504 (object 0x80b67ce8, a org.netbeans.modules.ruby.rubyproject.gems.GemPanel), which is held by "Default RequestProcessor" Java stack information for the threads listed above: =================================================== "Default RequestProcessor": at java.awt.Container.clearCurrentFocusCycleRootOnHide(Container.java:3124) - waiting to lock <0x7e2d1218> (a java.awt.Component$AWTTreeLock) at java.awt.Component.hide(Component.java:1446) at java.awt.Component.show(Component.java:1421) at java.awt.Component.setVisible(Component.java:1372) at javax.swing.JComponent.setVisible(JComponent.java:2610) at org.netbeans.modules.ruby.rubyproject.gems.GemPanel.updateGems(GemPanel.java:200) - locked <0x80b67ce8> (a org.netbeans.modules.ruby.rubyproject.gems.GemPanel) at org.netbeans.modules.ruby.rubyproject.gems.GemPanel.access$3100(GemPanel.java:83) at org.netbeans.modules.ruby.rubyproject.gems.GemPanel$3.run(GemPanel.java:936) - locked <0x7daa0000> (a org.netbeans.modules.ruby.rubyproject.gems.GemPanel$3) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) "AWT-EventQueue-1": at java.awt.Component.getName(Component.java:787) - waiting to lock <0x80b67ce8> (a org.netbeans.modules.ruby.rubyproject.gems.GemPanel) at com.sun.java.swing.plaf.gtk.GTKStyle.getColor(GTKStyle.java:176) at javax.swing.plaf.synth.SynthLookAndFeel.paintRegion(SynthLookAndFeel.java:367) at javax.swing.plaf.synth.SynthLookAndFeel.update(SynthLookAndFeel.java:331) at javax.swing.plaf.synth.SynthPanelUI.update(SynthPanelUI.java:94) at javax.swing.JComponent.paintComponent(JComponent.java:763) at javax.swing.JComponent.paint(JComponent.java:1027) at javax.swing.JComponent.paintChildren(JComponent.java:864) - locked <0x7e2d1218> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:1036) at javax.swing.JComponent.paintChildren(JComponent.java:864) - locked <0x7e2d1218> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paint(JComponent.java:1036) at javax.swing.JLayeredPane.paint(JLayeredPane.java:564) at javax.swing.JComponent.paintChildren(JComponent.java:864) - locked <0x7e2d1218> (a java.awt.Component$AWTTreeLock) at javax.swing.JComponent.paintToOffscreen(JComponent.java:5129) at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:285) at javax.swing.RepaintManager.paint(RepaintManager.java:1128) at javax.swing.JComponent.paint(JComponent.java:1013) at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:21) at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:60) at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:97) at java.awt.Container.paint(Container.java:1797) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:734) at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:679) at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:659) at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209) at java.awt.EventQueue.dispatchEvent(EventQueue.java:597) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:177) at java.awt.Dialog$1.run(Dialog.java:1039) at java.awt.Dialog$3.run(Dialog.java:1091) at java.security.AccessController.doPrivileged(Native Method) at java.awt.Dialog.show(Dialog.java:1089) at org.netbeans.core.windows.services.NbPresenter.superShow(NbPresenter.java:834) at org.netbeans.core.windows.services.NbPresenter.doShow(NbPresenter.java:868) at org.netbeans.core.windows.services.NbPresenter.run(NbPresenter.java:856) at org.netbeans.core.windows.services.NbPresenter.run(NbPresenter.java:104) at org.openide.util.Mutex.doEventAccess(Mutex.java:1223) at org.openide.util.Mutex.readAccess(Mutex.java:242) at org.netbeans.core.windows.services.NbPresenter.show(NbPresenter.java:841) at java.awt.Component.show(Component.java:1419) at java.awt.Component.setVisible(Component.java:1372) at java.awt.Window.setVisible(Window.java:801) at java.awt.Dialog.setVisible(Dialog.java:979) at org.netbeans.modules.ruby.rubyproject.gems.GemAction.showGemManager(GemAction.java:88) at org.netbeans.modules.ruby.rubyproject.gems.GemAction.performAction(GemAction.java:56) at org.openide.util.actions.CallableSystemAction$1.run(CallableSystemAction.java:118) at org.netbeans.modules.openide.util.ActionsBridge.doPerformAction(ActionsBridge.java:77) at org.openide.util.actions.CallableSystemAction.actionPerformed(CallableSystemAction.java:114) 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:1216) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257) at java.awt.Component.processMouseEvent(Component.java:6038) at javax.swing.JComponent.processMouseEvent(JComponent.java:3265) at java.awt.Component.processEvent(Component.java:5803) at java.awt.Container.processEvent(Container.java:2058) at java.awt.Component.dispatchEventImpl(Component.java:4410) at java.awt.Container.dispatchEventImpl(Container.java:2116) at java.awt.Component.dispatchEvent(Component.java:4240) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916) at java.awt.Container.dispatchEventImpl(Container.java:2102) at java.awt.Window.dispatchEventImpl(Window.java:2429) at java.awt.Component.dispatchEvent(Component.java:4240) at java.awt.EventQueue.dispatchEvent(EventQueue.java:599) 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) Found 1 deadlock.
I changed priority to P1. Because if NetBeans becomes deadlock, I can't do anything. I think this is fit for following priority guideline: - Product feature does not work, no workaround exists. - User's data are corrupted or lost.
Tor, I remember that you solved some issue (month or two ago) which has similarities to this one. It was something with getName() and GTK. Probably exactly the same issue here?
Hi, thanks for the report. Can you please let us know how often this happens, approximately? Is it rare, or is it almost all the time? org.netbeans.modules.ruby.rubyproject.gems.GemPanel is calling Swing code outside of the AWT thread, which is suspicious and probably wrong.
It's not always, but it happens every 5 or 6 times. I can reproduce this on Windows and Linux(Ubuntu), and I can't find any difference on each platform.(It happens every 5 or 6 times.)
I had a quick look at this as asked, seems that Petr's evaluation is correct - likely caused by calling non thread-safe Swing methods from a non-EDT thread. I spotted the following methods in the GemPanel class that contain such invocations: refreshUpdated(); refreshNew(); refreshInstalled(); updateGems(); I guess the expensive operations in the class that should be called outside of the event thread are GemManager#reloadInstalledGems, GemManager#reloadAvailableGems and GemManager#reload, right? With this assumption, I'm attaching a patch that changes the methods listed above to be invoked in the event thread.
Created attachment 53486 [details] GemPanel patch
Fixed in trunk. Thanks a lot for the patch emononen, however I fixed it slightly differently. I added assertions to all the methods that need to be invoked on the event dispatch thread, and in the two methods that are intentionally running off the AWT thread (slow network operations that shouldn't block the UI), I perform the first half in the other thread, and then perform the second half (the UI update) in the event thread. This code is very similar to code for the Rails Plugin manager, which I also fixed. IDE:------------------------------------------------- IDE: [11/26/07 8:26 PM] Committing started Checking in railsprojects/src/org/netbeans/modules/ruby/railsprojects/plugins/PluginPanel.java; /cvs/ruby/railsprojects/src/org/netbeans/modules/ruby/railsprojects/plugins/PluginPanel.java,v <-- PluginPanel.java new revision: 1.11; previous revision: 1.10 done Checking in platform/src/org/netbeans/modules/ruby/platform/gems/GemPanel.java; /cvs/ruby/platform/src/org/netbeans/modules/ruby/platform/gems/GemPanel.java,v <-- GemPanel.java new revision: 1.3; previous revision: 1.2 done IDE: [11/26/07 8:26 PM] Committing finished IDE: [11/26/07 8:26 PM] Diffing finished The fix can be verified in build #5487 or later from http://deadlock.netbeans.org/hudson/job/ruby/ . The only remaining question is whether we want to backport this to 6.0 - the timing isn't great since we have an FCS candidate build that appears to be solid enough to release, so we'd be holding up the release for this single issue. Personally, I don't think we should; this code is old (it was the same way in beta, RC1 and RC2) and we've only received a single deadlock report on it, so clearly it's limited in scope. (I can't reproduce it on my own Ubuntu 7.10 system). Finally, I don't think the Gem manager is critical functionality that warrants holding up the whole release. So my vote would be for this bug fix to go out on Auto Update as soon as possible.
This is P1 issue. So if possible, please fix this before FCS release. Because I think now NetBeans team should fix bugs as much as possible. Especially any P1 issues should be fixed before FCS release. (And I also heard after RC release, NetBeans team only fix P1 issue.) Many users report bug before FCS release, that means we spend much time to test NetBeans 6.0. So please don't ignore our effort.(to invest bug, to reproduce bug and to report bug.) I know it is not good time to change 6.0 branch now. But after FCS release, more and more users will use NetBeans Ruby Pack. So I'm worry this will be problem after FCS release. I personally suffer this issue many times. And I killed NetBeans process many time.
Hello abs, do you mean that you downloaded the build #5487, tested it and didn't reproduce the deadlock? This is what we really need since time is running out. We can't reproduce it ourselves and while I understand your motivation to persuade us to fix this issue in FCS, it does not help. On the other hand prompt verification does. Unfortunately it seems we lost one day since you are most probably located somewhere in PST and thus we will know your standpoint on Wednesday CET which is indeed very late. Thanks for your help, -Jirka
I've download build #5500. I couldn't reproduce deadlock. But this will not be a proof that this bug is fixed. Because this is thread related problem, so I can't show proof even if I can't reproduce this deadlock problem. I understand situation, but what kind of bugs does NetBeans team try to fix before FCS release?
How many times did you try to reproduce this? You mentioned that it happened once in 5-6 attempts. Could you then try 10-20 attempts to find out if the stability at least improved? As for your question, we try to fix as many bugs as we can but it depends how close we are to the planned release date. In Feature Freeze (after Beta) we fix all bugs. In High Resistance we fix only P1 and P2 bugs and in Code Freeze (after RC) we fix only showstoppers - P1 issues with no workaround that cause serious data loss, crashes, frequent deadlocks in basic functionality etc. All this is to avoid introducing regressions when the codebase is stabilizing. Thanks for your help!
Abs, rest assured, your effort wasn't wasted: The issue has been fixed in 6.1, and I will also fix it for 6.0 via the Auto Update mechanism. The question is whether we risk a schedule slip for this. As far as I understand, the last build for 6.0 has already been produced and is now being tested. That means that we'd have to go through the high resistance process, start the build over and start the last minute checks all over again (and slip) to get this bug fixed. Basically, in the 11th hour of a product cycle we have to make tradeoffs about which bugs we -have- to fix and which ones we can live with. Since this bug doesn't seem to be widespread (because neither QA nor I nor Martin could reproduce it, and I'm ALSO using Ubuntu 7.10 and Java JDK1.6.0_03-b05!, and nobody else has filed an issue on this) it seems like the bug scope is pretty limited. I will however, as promised, make sure this gets pushed to Auto Update. I was just talking to somebody yesterday about what the process is for pushing bugs out that way. I have a couple of other P1/P2 bugs that are similar to this one; I've found and fixed the problem in 6.1 but timing wise it may be too risky to touch the build at this point. If anybody wants to review the bug fix, the trunk integration is here: http://deadlock.netbeans.org/fisheye/changelog/netbeans?cs=MAIN:tor:20071126202644
I understand your effort. I worry about NetBeans doesn't have frequent release. I heard 6.1 will be released around JavaOne 2008. About auto update, I don't know how many times does NetBeans release critical bug fix. So far, as far as I know NetBeans didn't do it many times using auto update. If NetBeans has regular bug fix release like eclipse, I don't worry about it. But Tor says it will be fixed via auto update, so I should not worry about it. Thank you for your big effort to fix this bug and kind response to my question.
Thank -you- for reporting this, please file anything else you see as well. Our =ailure to use Auto Update sufficiently in the past is one of my pet peeves, and I'm pushing for us to take greater advantage of it.
According user's comment, marking as VERIFIED.
Created attachment 53732 [details] Patch of fix merged to the release60 branch
The fix has been ported into the release60_fixes branch. Checking in railsprojects/src/org/netbeans/modules/ruby/railsprojects/plugins/PluginPanel.java; /cvs/ruby/railsprojects/src/org/netbeans/modules/ruby/railsprojects/plugins/PluginPanel.java,v <-- PluginPanel.java new revision: 1.10.4.1; previous revision: 1.10 done Checking in projects/src/org/netbeans/modules/ruby/rubyproject/gems/GemPanel.java; /cvs/ruby/projects/src/org/netbeans/modules/ruby/rubyproject/gems/Attic/GemPanel.java,v <-- GemPanel.java new revision: 1.11.4.1; previous revision: 1.11 done
The similar bug has been occurred at issue 121694 "deadlock when resolve data sources". http://www.netbeans.org/issues/show_bug.cgi?id=121694