Bug 122199 - NetBeans becomes deadlock during Ruby Gems.
NetBeans becomes deadlock during Ruby Gems.
Status: VERIFIED FIXED
Product: ruby
Classification: Unclassified
Component: Gems
6.x
All All
: P1 (vote)
: 6.x
Assigned To: Torbjorn Norbye
issues@ruby
release60_fixes_candidate1, release60...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-17 10:04 UTC by abs
Modified: 2008-02-18 02:38 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
GemPanel patch (3.29 KB, patch)
2007-11-26 12:52 UTC, Erno Mononen
Details | Diff
Patch of fix merged to the release60 branch (18.43 KB, patch)
2007-11-30 19:05 UTC, Torbjorn Norbye
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description abs 2007-11-17 10:04:11 UTC
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.
Comment 1 abs 2007-11-22 13:00:02 UTC
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.
Comment 2 Martin Krauskopf 2007-11-22 13:16:37 UTC
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?
Comment 3 Petr Jiricka 2007-11-23 13:26:32 UTC
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.
Comment 4 abs 2007-11-23 15:32:35 UTC
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.)
Comment 5 Erno Mononen 2007-11-26 12:51:38 UTC
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.
Comment 6 Erno Mononen 2007-11-26 12:52:32 UTC
Created attachment 53486 [details]
GemPanel patch
Comment 7 Torbjorn Norbye 2007-11-26 20:34:25 UTC
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.
Comment 8 abs 2007-11-26 23:32:27 UTC
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.
Comment 9 Jiri Kovalsky 2007-11-27 08:59:05 UTC
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
Comment 10 abs 2007-11-27 14:40:39 UTC
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?
Comment 11 Jiri Kovalsky 2007-11-27 15:00:57 UTC
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!
Comment 12 Torbjorn Norbye 2007-11-27 17:09:42 UTC
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
Comment 13 abs 2007-11-27 23:46:07 UTC
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.
Comment 14 Torbjorn Norbye 2007-11-28 01:00:31 UTC
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.
Comment 15 Petr Blaha 2007-11-30 16:16:02 UTC
According user's comment, marking as VERIFIED.
Comment 16 Torbjorn Norbye 2007-11-30 19:05:58 UTC
Created attachment 53732 [details]
Patch of fix merged to the release60 branch
Comment 17 pgebauer 2007-12-03 19:54:23 UTC
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
Comment 18 liujiaguang 2008-02-18 02:38:25 UTC
The similar bug has been occurred at issue 121694 "deadlock when resolve data sources".
http://www.netbeans.org/issues/show_bug.cgi?id=121694


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo