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
now.
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?
Thanks,
David
--
David Rothenberger ---- daver...@acm.org
yo-yo, n.:
Something that is occasionally up but normally down.
(see also Computer).
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
