Re: [BUG] Halt during fetch on MacOS

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

 



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?


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
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail


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