On Wed, Jun 3, 2015 at 1:05 PM, Thierry Goubier
<thierry.goub...@gmail.com> wrote:
> 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.
As a workaround and investigation, can you wrap the "git banch" in a
script and experiment with extending the time.
#!/usr/local/mygitbranch
git branch $@
STATUS=$?
# sleep 1
exit STATUS
http://www.tldp.org/LDP/abs/html/exit-status.html
http://stackoverflow.com/questions/18492443/pass-all-parameters-of-one-shell-script-to-another
cheers -ben
