Re: git-svn hang starting with 20110721 snapshot.

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Aug  3 11:40, David Rothenberger wrote:
> On 8/3/2011 11:02 AM, Christopher Faylor wrote:
> > 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?

Better drop the large address stuff for now.  Since the heap is now in
the large addres area(*), and since mmaps will go there, too(*), we have
basically a lot more free space in the area up to 0x7fffffff.  I also
expect that the new rebase will help a lot.  It supports a rebase
database which keep track of rebase addresses, rebaseall does not keep
64K free space between DLLs anymore (this isn't necessary for a long
time, but rebaseall never catched up), and rebase now supports a -i flag
which allows to inspect DLL addresses for collisions.  If you're
curious, the CVS repository is on cygwin.com: cvs -d
:pserver:anoncvs@cygwin.com:/cvs/cygwin-apps co rebase


Corinna


(*) On machines supporting large addresses.  For instance, XP with the
    /3GB boot flag, or 64 bit Windows.  And the executable needs to have
    the large-address awareness flag set as well, that's quite important.
    It's not very helpful that our executables don't have this flag set
    by default, but there's the peflags tool and future GCCs are supposed
    to set the large-address awareness flag by default.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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