From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, mlevedahl@gmail.com,
Jonathan Nieder <jrnieder@gmail.com>
Subject: Re: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)
Date: Thu, 09 May 2013 18:18:01 +0100 [thread overview]
Message-ID: <518BDA49.400@ramsay1.demon.co.uk> (raw)
In-Reply-To: <51890F48.3090409@web.de>
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
next prev parent reply other threads:[~2013-05-09 17:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-03 23:14 What's cooking in git.git (May 2013, #01; Fri, 3) Junio C Hamano
2013-05-07 14:27 ` Problems with Windows, Was: " Torsten Bögershausen
2013-05-08 0:30 ` Mark Levedahl
2013-05-08 15:01 ` Torsten Bögershausen
2013-05-09 17:18 ` Ramsay Jones [this message]
2013-05-14 19:37 ` Torsten Bögershausen
2013-05-14 22:41 ` Philip Oakley
2013-05-15 6:19 ` Tay Ray Chuan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=518BDA49.400@ramsay1.demon.co.uk \
--to=ramsay@ramsay1.demon.co.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=mlevedahl@gmail.com \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).