Sending the SIGUSR1 signal prints this: 0xb84e2a7c s NonInteractiveUIManager(UIManager)>defer: 0xb84e29f4 s PharoCommandLineHandler class>activateWith: 0xb84f5e08 s [] in BasicCommandLineHandler>activateSubCommand: 0xb84e2e98 s BlockClosure>on:do: 0xb84e2970 s BasicCommandLineHandler>activateSubCommand: 0xb84e2914 s BasicCommandLineHandler>handleSubcommand 0xb84f5e64 s BasicCommandLineHandler>handleArgument: 0xb84e281c s [] in BasicCommandLineHandler>activate 0xb84e2878 s BlockClosure>on:do: 0xb84e27a0 s BasicCommandLineHandler>activate 0xb84f5cf4 s [] in BasicCommandLineHandler class>startUp: 0xb84f5d50 s BlockClosure>cull: 0xb84f5dac s [] in SmalltalkImage>executeDeferredStartupActions: 0xb84e2ef4 s BlockClosure>on:do: 0xb84e0ee4 s SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: 0xb84e0e1c s SmalltalkImage>executeDeferredStartupActions: 0xb84e0c1c s SmalltalkImage>startupImage:snapshotWorked: 0xb84e0170 s SmalltalkImage>snapshot:andQuit: 0xb84e04ac s [] in WorldState class>saveAndQuit 0xb84e0508 s BlockClosure>ensure: 0xb84d3274 s CursorWithMask(Cursor)>showWhile: 0xb84d3208 s WorldState class>saveAndQuit 0xb84e0564 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0xb84e05c0 s BlockClosure>ensure: 0xb84d3198 s CursorWithMask(Cursor)>showWhile: 0xb84d30c8 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: 0xb84d306c s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: 0xb84e061c s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: 0xb84e0678 s MouseButtonEvent>sentTo: 0xb84e06d4 s ToggleMenuItemMorph(Morph)>handleEvent: 0xb84e0730 s MorphicEventDispatcher>dispatchDefault:with: 0xb84e078c s MorphicEventDispatcher>handleMouseUp: 0xb84e07e8 s MouseButtonEvent>sentTo: 0xb84e0844 s [] in MorphicEventDispatcher>dispatchEvent:with: 0xb84e08a0 s BlockClosure>ensure: 0xb84d2fec s MorphicEventDispatcher>dispatchEvent:with: 0xb84e08fc s ToggleMenuItemMorph(Morph)>processEvent:using: 0xb84d2f08 s MorphicEventDispatcher>dispatchDefault:with: 0xb84d2f64 s MorphicEventDispatcher>handleMouseUp: 0xb84e01cc s MouseButtonEvent>sentTo: 0xb84e0228 s [] in MorphicEventDispatcher>dispatchEvent:with: 0xb84e0284 s BlockClosure>ensure: 0xb84d2e88 s MorphicEventDispatcher>dispatchEvent:with: 0xb84e02e0 s MenuMorph(Morph)>processEvent:using: 0xb84e033c s MenuMorph(Morph)>processEvent: 0xb84e0398 s MenuMorph>handleFocusEvent: 0xb84e03f4 s [] in HandMorph>sendFocusEvent:to:clear: 0xb84e0450 s BlockClosure>on:do: 0xb84d2d88 s WorldMorph(PasteUpMorph)>becomeActiveDuring: 0xb84d2d10 s HandMorph>sendFocusEvent:to:clear: 0xb84d2e00 s HandMorph>sendEvent:focus:clear: 0xb84d2c9c s HandMorph>sendMouseEvent: 0xb84e0958 s HandMorph>handleEvent: 0xb84e09b4 s HandMorph>processEvents 0xb84e0a10 s [] in WorldState>doOneCycleNowFor: 0xb84e0a6c s Array(SequenceableCollection)>do: 0xb84e0ac8 s WorldState>handsDo: 0xb84d2ba4 s WorldState>doOneCycleNowFor: 0xb84e0b24 s WorldState>doOneCycleFor: 0xb84e0b80 s WorldMorph>doOneCycle 0xb84a0b60 s [] in MorphicUIManager>spawnNewProcess 0xb84a0adc s [] in BlockClosure>newProcess
Most recent primitives [..] On Wed, Jun 3, 2015 at 8:32 AM, Jose San Leandro <jose.sanlean...@osoco.es> wrote: > Hi Dave, Thierry, > > Here's what I get in all recent attempts: > > [..] > /2.3/lib/gradle-launcher-2.3.jar org.gradle.launcher.GradleMain assemble > 18620 pts/5 S+ 0:00 | \_ bash > /home/chous/toolbox/pharo/pharo Pharo.image config > gitfiletree:///home/chous/osoco/open-badges/game-core > ConfigurationOfGameCore --install=bleedingEdge > 18635 pts/5 R+ 5:07 | \_ > /home/chous/toolbox/pharo/pharo-vm/pharo --nodisplay Pharo.image config > gitfiletree:///home/chous/osoco/open-badges/game-core > ConfigurationOfGameCore --install=bleedingEdge > 32741 pts/5 Z+ 0:00 | \_ [git] <defunct> > > > > > 2015-06-03 7:05 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com>: > >> Hi Dave, >> >> Le 03/06/2015 03:15, David T. Lewis a écrit : >> >>> Hi Thierry and Jose, >>> >>> I am reading this thread with interest and will help if I can. >>> >>> I do have one idea that we have not tried before. I have a theory that >>> this may >>> be an intermittent problem caused by SIGCHLD signals (from the external >>> OS process >>> when it exits) being missed by the >>> UnixOSProcessAccessor>>grimReaperProcess >>> that handles them. >>> >>> If this is happening, then I may be able to change grimReaperProcess to >>> work around the problem. >>> >>> When you see the OS deadlock condition, are you able tell if your Pharo >>> VM >>> process has subprocesses in the zombie state (indicating that >>> grimReaperProcess >>> did not clean them up)? The unix command "ps -axf | less" will let you >>> look >>> at the process tree and that may give us a clue if this is happening. >>> >> >> I found it very easy to reproduce and I do have a zombie children process >> to the pharo process. >> >> Interesting enough, the lock-up happens in a very specific place, a call >> to git branch, which is a very short command returning just a few >> characters (where all other commands have longuer outputs). Reducing the >> frequency of the calls to git branch by a bit of caching reduces the >> chances of a lock-up. >> >> Thanks, >> >> Dave >> >> Thanks! >>> >>> Dave >>> >>> >>> >>> >> >> > 2015-06-03 8:32 GMT+02:00 Jose San Leandro <jose.sanlean...@osoco.es>: > Hi Dave, Thierry, > > Here's what I get in all recent attempts: > > [..] > /2.3/lib/gradle-launcher-2.3.jar org.gradle.launcher.GradleMain assemble > 18620 pts/5 S+ 0:00 | \_ bash > /home/chous/toolbox/pharo/pharo Pharo.image config > gitfiletree:///home/chous/osoco/open-badges/game-core > ConfigurationOfGameCore --install=bleedingEdge > 18635 pts/5 R+ 5:07 | \_ > /home/chous/toolbox/pharo/pharo-vm/pharo --nodisplay Pharo.image config > gitfiletree:///home/chous/osoco/open-badges/game-core > ConfigurationOfGameCore --install=bleedingEdge > 32741 pts/5 Z+ 0:00 | \_ [git] <defunct> > > > > > 2015-06-03 7:05 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com>: > >> Hi Dave, >> >> Le 03/06/2015 03:15, David T. Lewis a écrit : >> >>> Hi Thierry and Jose, >>> >>> I am reading this thread with interest and will help if I can. >>> >>> I do have one idea that we have not tried before. I have a theory that >>> this may >>> be an intermittent problem caused by SIGCHLD signals (from the external >>> OS process >>> when it exits) being missed by the >>> UnixOSProcessAccessor>>grimReaperProcess >>> that handles them. >>> >>> If this is happening, then I may be able to change grimReaperProcess to >>> work around the problem. >>> >>> When you see the OS deadlock condition, are you able tell if your Pharo >>> VM >>> process has subprocesses in the zombie state (indicating that >>> grimReaperProcess >>> did not clean them up)? The unix command "ps -axf | less" will let you >>> look >>> at the process tree and that may give us a clue if this is happening. >>> >> >> I found it very easy to reproduce and I do have a zombie children process >> to the pharo process. >> >> Interesting enough, the lock-up happens in a very specific place, a call >> to git branch, which is a very short command returning just a few >> characters (where all other commands have longuer outputs). Reducing the >> frequency of the calls to git branch by a bit of caching reduces the >> chances of a lock-up. >> >> Thanks, >> >> Dave >> >> Thanks! >>> >>> Dave >>> >>> >>> >>> >> >> >
