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

2013-05-15 Thread Tay Ray Chuan 
On Wed, May 15, 2013 at 3:37 AM, Torsten Bögershausen tbo...@web.de wrote:
 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

I also managed to run into the intermittent hanging of git-fetch when
running t5510. What I do is keep running the test till it stalls:

  while [ $? -eq 0 ]; do date; ./t5510-fetch.sh -i -v; done

Almost always the git-fetch output looks like this:

  remote: Counting objects: 7, done.
  remote: Compressing objects: 100% (5/5), done.
  remote: Total 6 (delta 1), reused 0 (delta 0)

However my task manager indicates that git-upload-pack or whatever
that runs on the remote side is absent, only git-fetch is waiting - 0
I/O, 0 cswitches, nilda. I tried getting a gdb backtrace but I get ???
nonsense, despite having compiled git with `-g -O0`. I also noticed
there were a couple of threads. This is my gdb session:

$ gdb --pid=7936
GNU gdb (GDB) 7.6.50.20130508-cvs (cygwin-special)
...
Attaching to process 7936
[New Thread 7936.0x1c7c]
[New Thread 7936.0x6b8]
[New Thread 7936.0xd20]
[New Thread 7936.0x1cf8]
[New Thread 7936.0x1b24]
Reading symbols from /cygdrive/f/files/coding/git/git.exe...done.
(gdb) info thread
  Id   Target Id Frame
* 5Thread 7936.0x1b24 0x77c5000d in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  4Thread 7936.0x1cf8 0x77c5f8b1 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  3Thread 7936.0xd20 0x77c5f91d in ntdll!ZwWriteFile ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  2Thread 7936.0x6b8 0x77c5f8b1 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  1Thread 7936.0x1c7c 0x77c5f8b1 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5000d in ntdll!DbgBreakPoint () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77cdf896 in ntdll!DbgUiRemoteBreakin () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x775c5cca in ?? ()
#3  0x in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 7936.0x1cf8)]
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7573149d in WaitForSingleObjectEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x0148 in ?? ()
#4  0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 7936.0xd20)]
#0  0x77c5f91d in ntdll!ZwWriteFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f91d in ntdll!ZwWriteFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f91d in ntdll!ZwWriteFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7572dec1 in WriteFile () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x009c in ?? ()
#4  0x in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 7936.0x6b8)]
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7573149d in WaitForSingleObjectEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x001c in ?? ()
#4  0x in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 7936.0x1c7c)]
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7573149d in WaitForSingleObjectEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x0034 in ?? ()
#4  0x in ?? ()

--
Cheers,
Ray Chuan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2013-05-14 Thread Torsten Bögershausen 
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 21)
 
 real172m25.311s
 user132m15.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 3backflow 
 
 -   } 
 -   $maybe_fail_fi git fast-import --cat-blob-fd=3 stream 3backflow 
 
 -   wait $!
 +   $maybe_fail_svnfe test-svn-fe $input 3backflow
 +   } |
 +   $maybe_fail_fi git fast-import --cat-blob-fd=3 3backflow
  }
 
  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

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

2013-05-14 Thread Philip Oakley 

sorry about the MUA mangling - reply at end.
- Original Message - 
From: Torsten Bögershausen tbo...@web.de

To: Ramsay Jones ram...@ramsay1.demon.co.uk
Cc: Torsten Bögershausen tbo...@web.de; Junio C Hamano
gits...@pobox.com; git@vger.kernel.org; mleved...@gmail.com;
Jonathan Nieder jrnie...@gmail.com; j...@kdbg.org; msysGit
msys...@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 21)

real172m25.311s
user132m15.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
3backflow 
-   } 
-   $maybe_fail_fi git fast-import --cat-blob-fd=3 stream
3backflow 
-   wait $!
+   $maybe_fail_svnfe test-svn-fe $input 3backflow
+   } |
+   $maybe_fail_fi git fast-import --cat-blob-fd=3 3backflow
 }

 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

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

2013-05-09 Thread Ramsay Jones 
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 21)

real172m25.311s
user132m15.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 3backflow 
-   } 
-   $maybe_fail_fi git fast-import --cat-blob-fd=3 stream 3backflow 
-   wait $!
+   $maybe_fail_svnfe test-svn-fe $input 3backflow
+   } |
+   $maybe_fail_fi git fast-import --cat-blob-fd=3 3backflow
 }

 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


--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2013-05-08 Thread Torsten Bögershausen 
On 2013-05-08 02.30, Mark Levedahl wrote:
 On 05/07/2013 10:27 AM, 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
 /Torsten

 
 I have run into very similar problems trying to test these patches, so I 
 declined to reply thinking someone else might have better or at least 
 explicable results. I am able to build git on cygwin 1.7 using the proposed 
 patches, it seems to work, but I've run into strange problems such as the 
 main git repo becoming corrupted, no idea how or why.
 
 Mark

I tried 1.8.3-rc1 on a different PC, and it seems to have the same hanging.
So I will do some bisecting on master, and try to find out more.


 
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2013-05-07 Thread Torsten Bögershausen 
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
/Torsten








--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

2013-05-07 Thread Mark Levedahl 

On 05/07/2013 10:27 AM, 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
/Torsten



I have run into very similar problems trying to test these patches, so I 
declined to reply thinking someone else might have better or at least 
explicable results. I am able to build git on cygwin 1.7 using the 
proposed patches, it seems to work, but I've run into strange problems 
such as the main git repo becoming corrupted, no idea how or why.


Mark

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html