Re: Re: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)

["Philip Oakley" <philipoakley@iee.org>]

sorry about the MUA mangling - reply at end.
----- Original Message ----- 
From: "Torsten Bögershausen" <tboegi@web.de>
To: "Ramsay Jones" <ramsay@ramsay1.demon.co.uk>
Cc: "Torsten Bögershausen" <tboegi@web.de>; "Junio C Hamano"
<gitster@pobox.com>; <git@vger.kernel.org>; <mlevedahl@gmail.com>;
"Jonathan Nieder" <jrnieder@gmail.com>; <j6t@kdbg.org>; "msysGit"
<msysgit@googlegroups.com>
Sent: Tuesday, May 14, 2013 8:37 PM
Subject: [msysGit] Re: Problems with Windows, Was: What's cooking in
git.git (May 2013, #01; Fri, 3)


On 2013-05-09 19.18, Ramsay Jones wrote:
> Torsten Bögershausen wrote:
>> On 2013-05-04 01.14, Junio C Hamano wrote:
>>>
>>>  Cygwin portability; both were reviewed by Jonathan, and the tip one
>>>  seems to want a bit further explanation.  Needs positive report
>>>  from Cygwin 1.7 users who have been on 1.7 to make sure it does not
>>>  regress for them.
>>
>> I was trying to verify that cygwin 1.7 is still Ok, but got puzzled.
>>
>> Running the test suite under cygwin doesn't seem to work any more
>> (?):
>>
>> Scenario 1:
>> The PC is running alone, and goes into the screen saver.
>> Pressing CTRL-ALT-DEL didn't get any effect.
>>
>> Scenario 2:
>> The PC didn't react any more, when the test suite was run in
>> background.
>> In 3 or 4 cases the PC needed to be reboot hardly.
>>
>> Using the commits before and after this change makes the test suite
>> hang
>> as well at some point, then it hangs somewhere at TC 3000--4000.
>>
>> Scenario 4:
>> The I disabled the screensaver, upgdated cygwin,
>>  and went back to an older commit:
>> The latest run from commit 52d63e70, April 28,
>> hangs in TC 5500, ok 26 clone shallow object count.
>>
>> I can see 2 times
>> git.exe pull --depth 4 ..A
>>
>> Scenario 5:
>> The run of today 1.8.3-rc1, hangs in t5510,
>> some git.exe are running fetch. (or pull)
>>
>>
>> It seems as if some process/exes are not terminated
>> in the way it should be.
>>
>> I will try on a different machine,
>> comments are wellcome
>
> Hmm, I'm a little puzzled, but not shocked. ;-)
>
> Somebody, I forget who, had already tested Jonathan's patch
> on cygwin 1.7 successfully and my follow up patch should be
> a no-op on cygwin 1.7; so I'm puzzled! (The high risk should
> have been on cygwin 1.5).
>
> I'm not shocked because running the test-suite on cygwin has
> been a bit of a magical mystery tour for quite some time.
>
> In about 2007, I could not run the test-suite for about six
> to nine months; it would randomly wedge my laptop solid - I had
> to pull the power-cord out in order to re-boot. (I suspect that
> commit 9cb18f56fde may have cured that particular problem, but
> don't quote me on that - I didn't investigate at the time.)
>
> I have noticed that running the tests with 'prove' is more likely
> to prove successful, so my config.mak looks like:
>
>     $ cat config.mak
>     NO_SVN_TESTS=1
>     GIT_TEST_OPTS=--no-color
>     NO_GETTEXT=1
>     DEFAULT_TEST_TARGET=prove
>     GIT_PROVE_OPTS='--timer'
>     $
>
> I currently run the tests like so:
>
>     $ time $(GIT_SKIP_TESTS='t0061.3 t0070.3 t4130 t9010 t9300' make
> test \
>     >test-outp13 2>&1)
>
>     real    172m25.311s
>     user    132m15.133s
>     sys     66m43.122s
>     $
>
> The t0061.3 and t0070.3 failures don't require much discussion. The
> t4130
> failure is an intermittent "racy git" issue that has been on my TODO
> list
> for several years. t9300 also fails intermittently. However, t9010
> fails
> every time for me, hanging the test suite (although ^C interrupts it
> just
> fine).
>
> I have a "fix" for t9010 that looks like:
>
>     diff --git a/t/t9010-svn-fe.sh b/t/t9010-svn-fe.sh
>     index b7eed24..4d01e3b 100755
>     --- a/t/t9010-svn-fe.sh
>     +++ b/t/t9010-svn-fe.sh
>     @@ -22,10 +22,9 @@ try_dump () {
>             maybe_fail_fi=${3:+test_$3} &&
>
>             {
>     -               $maybe_fail_svnfe test-svn-fe "$input" >stream
> 3<backflow &
>     -       } &&
>     -       $maybe_fail_fi git fast-import --cat-blob-fd=3 <stream
> 3>backflow &&
>     -       wait $!
>     +               $maybe_fail_svnfe test-svn-fe "$input" 3<backflow
>     +       } |
>     +       $maybe_fail_fi git fast-import --cat-blob-fd=3 3>backflow
>      }
>
>      properties () {
>
> but I have not tested this patch enough to be happy to submit it (I
> have
> some suspicions that it would still fail intermittently, just like
> t9300).
>
> Also, commit 7bc0911d ("test-lib: Fix say_color () not to interpret
> \a\b\c
> in the message", 11-10-2012) caused several random test failures.
> (don't ask
> me why). So, before each test run, I have to apply the following:
>
>     diff --git a/t/test-lib.sh b/t/test-lib.sh
>     index f50f834..ed32b7f 100644
>     --- a/t/test-lib.sh
>     +++ b/t/test-lib.sh
>     @@ -230,7 +230,7 @@ else
>             say_color() {
>                     test -z "$1" && test -n "$quiet" && return
>                     shift
>     -               printf "%s\n" "$*"
>     +               echo -E "$*"
>             }
>      fi
>
> which effectively reverts that commit.
>
> So, as I said, a "magical mystery tour". :-D
>
> ATB,
> Ramsay Jones
>
>
First of all,
the patch we are talking about does not any regrssions at my side.

Second,
I was able to do some testing.
The hanging is not 100% reproducable, and I had one hanging in Git 1.8.1

Turning the screen saver off in Win XP helps that the machine reacts,
and using process explorer showed that the hanging is happening
in test cases doing "git fetch" (or git pull) from a local repository.
What I can see is one git-fetch.exe together with git-upload-pack.exe

>From my understanding is the upload-pack a "forked" exe from the main
git,
and they should talk to each other.
One interesting part is in run-command.c, and there we have different
code for MiNGW
and the "rest of the world", Linux/Unix/cygwin.

I tried to steal the code around mingw_spawnvpe(), but could not get
that working (yet).

Another approach could be to steal the pipe() from mingw.

Does anybody know if we have a similar problem (hanging TC which test
fetch/pull)
in MinGW/msysGit?

If no, why not ;-)

Thanks for reading
/Torsten

---
Torsten,

There have been on-going sporadic problems with the push / fetch over
various protocols which haven't been tracked down to an exact point that
affords a proper fix. The reports appear to cover both ssh and git 
protocols. In some cases it could be the users ssh client.

The skill sets and developer approaches to problem resolution in
Windowsland and *nixland do appear to be somewhat different ;-)

I posted a reply to an earlier report on
https://groups.google.com/group/msysgit/msg/fdabaa0e4f8a55a7?hl=en
From: "Philip Oakley" <philipoak...@iee.org>
Date: Fri, 8 Feb 2013 19:31:33 -0000
Local: Fri, Feb 8 2013 8:31 pm
Subject: Re: [msysGit] Unable to clone/fetch

[...]

This is my list of web pages on the issue that may be of help. Issue 457
has a good discussion. It looks to me as if this is a case of 'premature
optimisation' in Linux land (or the the opposite by microsoft) in the
way that the side band channels are set-up and info is exchanged. But I
haven't go any further than reading through the various reports,
thinking, and surmising (no practical work ;-).


If you are able to find a method to unwind the situation that causes the
deadlock it would be great for every one.
regards
Philip


Google :: "msysgit hangs when ssh fetch"
========================================
http://billauer.co.il/blog/2012/10/git-pull-windows-freeze-receive-pack/
 Change "side-band-64k" to "side-bond-64k" so it never gets used.


http://devnet.jetbrains.net/message/5473415?tstart=0
 remnants of several previous installations of Git. Sort the path
entries..


http://code.google.com/p/msysgit/issues/detail?id=74
 Issue 74: git remote update/git fetch fails via ssh


http://code.google.com/p/msysgit/issues/detail?id=161
 Issue 161: git-gui hangs on ssh for users with home directory mapped to
server share


http://code.google.com/p/msysgit/issues/detail?id=243
https://groups.google.com/forum/?fromgroups=#!topic/msysgit/mFnzYM3IA_4
 Re: Issue 243 in msysgit: ssh hangs a minute than goes to next line
without performing action


http://code.google.com/p/msysgit/issues/detail?id=361
 Issue 361: Clone/fetch/pull from github using git protocol hangs, http
works


http://code.google.com/p/msysgit/issues/detail?id=457
*** a good discussion.
 Issue 457: Push over git protocol hangs in msysGit
 The problematic commit is 0c499ea60f, which introduced the sideband
support in send_pack.



-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.