Re: [BUG] Halt during fetch on MacOS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Mar 2, 2014 at 6:36 AM, Max Horn <max@xxxxxxxxx> wrote:
>
> On 01.03.2014, at 00:26, Conley Owens <cco3@xxxxxxxxxxx> wrote:
>
>> $ git --version  # This is just the git from MacPorts
>> git version 1.8.5.5
>> $ sw_vers
>> ProductName:    Mac OS X
>> ProductVersion: 10.8.5
>> BuildVersion:   12F45
>
> I cannot reproduce this, neither with 1.8.5.5 nor with 1.9.0. I am also running Mac OS X 10.8.5.
>
> Note: I tried this both with you original test.sh, and also with a version were I replaced the ">" by ">>", as per Jeff's suggestion. It (as predicted) didn't make any difference).
>
> If this is a race condition, it might be easier to trigger it on slower hardware. I am running this on a 2012 MBP with 2.3 Ghz i7 and an SSD. What is your test machine?

Mac mini i7 with 1TB fusion drive and 16GB ram.

It also seemed to trigger more when grabbing larger repositories.
Replace"external/tinyxml2" with "docs/source.android.com" and you
might be more likely to trigger the issue.  You can also try
increasing the number of processes to spawn from 100 to 150.

>
>
> Cheers,
> Max
>
>>
>> test.sh
>> """""""""""""""""""""""""""""""""""""
>> #!/bin/bash
>> rungit() {
>>    mkdir $1
>>    GIT_DIR=$1 git init --bare
>>    echo '[remote "aosp"]' > $1/config
>>    echo '    url =
>> https://android.googlesource.com/platform/external/tinyxml2' >>
>> $1/config
>>    GIT_DIR=$1 git fetch aosp +refs/heads/master:refs/remotes/aosp/master
>>    rm -rf $1
>> }
>>
>> for i in $(seq 1 100)
>> do
>>    rungit testdir$i &
>> done
>> """""""""""""""""""""""""""""""""""""""
>> $ ./test.sh  # Warning! This script fetches ~40MB of data
>>
>> When everything cools, you can see that there are some fetches hanging
>> (typically).
>> $ ps | grep 'git fetch'
>> ...
>> 63310 ttys004    0:00.01 git fetch aosp
>> +refs/heads/master:refs/remotes/aosp/master
>> 63314 ttys004    0:00.01 git fetch aosp
>> +refs/heads/master:refs/remotes/aosp/master
>> 63319 ttys004    0:00.01 git fetch aosp
>> +refs/heads/master:refs/remotes/aosp/master
>> 63407 ttys004    0:00.00 git fetch aosp
>> +refs/heads/master:refs/remotes/aosp/master
>> 63414 ttys004    0:00.00 git fetch aosp
>> +refs/heads/master:refs/remotes/aosp/master
>> 63420 ttys004    0:00.00 git fetch aosp
>> +refs/heads/master:refs/remotes/aosp/master
>> ...
>>
>> You can look at the parent process of each and see that one half
>> spawned the other half, or you can look at the environment variables
>> for each to see that there are two processes operating in the same
>> directory for each directory where there's an issue.
>> $ echo "$(for pid in $(ps | grep 'git fetch' | grep -o '^[0-9]*'); do
>> ps -p $pid -wwwE | grep 'GIT_DIR=[^ ]*' -o; done)" | sort
>> GIT_DIR=testdir14
>> GIT_DIR=testdir14
>> GIT_DIR=testdir32
>> GIT_DIR=testdir32
>> GIT_DIR=testdir47
>> GIT_DIR=testdir47
>>
>> I've searched through the mailing list, but this doesn't seem to be a
>> known issue.  I've only seen this occur on macs (and with a good deal
>> of regularity).  It doesn't occur on my Ubuntu box.
>>
>> ~cco3
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]