git-svn hang starting with 20110721 snapshot.
Wed Aug 3 18:03:00 GMT 2011
On Wed, Aug 03, 2011 at 10:00:13AM -0400, Christopher Faylor wrote:
>On Wed, Aug 03, 2011 at 09:45:28AM -0400, Christopher Faylor wrote:
>>On Wed, Aug 03, 2011 at 10:44:27AM +0200, Corinna Vinschen wrote:
>>>On Aug 2 10:58, David Rothenberger wrote:
>>>> I use git-svn extensively in my day-to-day work, and I noticed with
>>>> recent snapshots that some of the git-svn commands are hanging. I
>>>> narrowed it down to the 20110721 snapshot. 20110713 is the last one
>>>> that works fine.
>>>> I realize this isn't exactly a STC, but I don't have the time right
>>>> now to narrow it down further (or the skills, really). I've attached
>>>> a script which reproduces the problem. It requires svn and
>>>> git-svn. In the script, the first "git svn init" command hangs with
>>>> 20110721, but the entire script succeeds with 20110713.
>>>> I hope this is enough information to track down the problem, because
>>>> I was absolutely LOVING the speed increase in 20110801.
>>>This is not enough for me. I tried your script on W7 32 bit and Server
>>>2008 R2 64 bit, using Cygwin from CVS as well as the 20110801 snapshot,
>>>in in no case can I reproduce a hang. The script runs fine (and fast):
>>I don't see a hang but I do see a:
>>error: cannot fork() for git-svn: Resource temporarily unavailable
>>I'll investigate that. Maybe it's related.
>Huh. I ran rebaseall before reporting the above but, on inspecting the
>output from strace, I saw that dlls were getting located in non-rebased
>locations. So, I ran rebaseall again. *Now* I see the hang. Weird.
>So I guess I can investigate the actual problem now. FWIW, strace
>reports that the child of a fork has died with a SIGSEGV but I don't see
>the location of the SIGSEGV in the strace output. So it will be a
>little tricky to track down.
It actually wasn't a SIGSEGV. It really was a strange rebase error.
Unfortunately, the error was silent both to the standard output and,
more irritatingly, to strace. I've checked in changes which now expose
The problem is during one of git's 1247 runs of perl, a dll gets
inexplicably relocated out of its comfort zone. Then when perl forks
the address that the dll was relocated to is in use. So: boom.
The good news is that the problem went away when I ran "peflagsall".
Does that help you David?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin