This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: git-svn hang starting with 20110721 snapshot.

On 8/3/2011 11:02 AM, Christopher Faylor wrote:
> 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 error.
> 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?

I failed to mention in my original report that I'm on W7 x64 and was
running with bigaddr=1 and all DLLs rebased from 0x89000000 down. I just
saw Corinna's email from this morning about the heap changes around
20110721, so that probably explains my problem.

I ran "rebaseall -o 0" and "peflagsall" and my test case is working fine

I'm a little worried, though, since git-svn and stgit were unusable for
me last month until I rebased everything about 0x8000000. (The
combination of python, perl, and tons of svn DLLs was just too much.)

What's the best approach now? Should I expect forking to work better
even with everything rebased from 0x7000000 down now that the heap is
above 2gb? Or should I rebase everything from 0xffff0000 down as Yaakov
is doing? Or should I start from somewhere in between?


David Rothenberger  ----

yo-yo, n.:
        Something that is occasionally up but normally down.
        (see also Computer).

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]