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.sanleandro@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.goubier@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.sanleandro@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.goubier@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