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 >> >> >> >> > >
