git-svn hang starting with 20110721 snapshot.

git-svn hang starting with 20110721 snapshot.

[David Rothenberger]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

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.

-- 
David Rothenberger  ----  daveroth@acm.org

Captain Penny's Law:
        You can fool all of the people some of the time, and
        some of the people all of the time, but you Can't Fool Mom.

[-- Attachment #2: reproduce.sh --]
[-- Type: text/plain, Size: 857 bytes --]

#!/bin/bash
D=/tmp/git-svn-problem.$$
mkdir $D
echo "Created $D"
#trap { x=$?; rm -fr $D; exit $x; } SIGINT SIGHUP EXIT

#D=$PWD
#rm -fr repos
#rm -fr work

R=${D}/repos
RURL=file://$R

echo "Creating an SVN repository and workspace."

# Create the SVN repository
svnadmin create $R

# Create a work space
W=${D}/work
svn co $RURL $W
cd $W
svn mkdir tags trunk branches
date > trunk/file1
svn add trunk/file1
svn ci -m 'Initial version'

# Initialize using git-svn
echo ""
echo "Initializing with git svn."
echo "This hangs with recent snapshots."
cd trunk
git svn init -s $RURL
rm file1
git svn fetch --all

echo ""
echo "Making a change in svn, then doing git svn rebase --all."
echo "git svn rebase --all also hangs."

# Make a change in svn
date > file1
svn ci -m 'Updated file1'

# git svn rebase --all
git reset --hard
git svn rebase --all
rm -fr $D


[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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

Re: git-svn hang starting with 20110721 snapshot.

[Corinna Vinschen]

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

  $ ./reproduce.sh
  Created /tmp/git-svn-problem.2528
  Creating an SVN repository and workspace.
  Checked out revision 0.
  A         tags
  A         trunk
  A         branches
  A         trunk/file1
  Adding         branches
  Adding         tags
  Adding         trunk
  Adding         trunk/file1
  Transmitting file data .
  Committed revision 1.

  Initializing with git svn.
  This hangs with recent snapshots.
  Initialized empty Git repository in /tmp/git-svn-problem.2528/work/trunk/.git/
	  A       file1
  r1 = 3a690f391f65e05607235e13e2baf15af222ea6a (refs/remotes/trunk)
  Checked out HEAD:
    file:///tmp/git-svn-problem.2528/repos/trunk r1

  Making a change in svn, then doing git svn rebase --all.
  git svn rebase --all also hangs.
  Sending        trunk/file1
  Transmitting file data .
  Committed revision 2.
  HEAD is now at 3a690f3 Initial version
	  M       file1
  r2 = 688e627bde2e5b2cdf7526edb9b34a21e2f816a2 (refs/remotes/trunk)
  First, rewinding head to replay your work on top of it...
  Fast-forwarded master to refs/remotes/trunk.

I see only one change in the 20110721 snapshot which *might* account for
this problem and that is the FIONREAD stuff, but actually even that is
unlikely since it just changes the error code returned from the ioctl
call (ENOTTY instead of EINVAL).


Corinna

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

Re: git-svn hang starting with 20110721 snapshot.

[Christopher Faylor]

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.

cgf

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

Re: git-svn hang starting with 20110721 snapshot.

[Christopher Faylor]

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.

cgf

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

Re: git-svn hang starting with 20110721 snapshot.

[Corinna Vinschen]

On Aug  3 10:00, 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.

Is git-svn using perl?  I have constant problems using perl after a 
rebase.  The problem starts with perl.exe(!) being rebased(!) to
0x50000000(!).  However, when rebasing perl.exe to 0x400000 where it
belongs, it doesn't work either.  Only reinstalling perl helped
afterwards.

Reini, could you please update the perl package so that the executable
is in its default place at 0x400000?


Corinna

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

Re: git-svn hang starting with 20110721 snapshot.

[Corinna Vinschen]

On Aug  3 16:56, Corinna Vinschen wrote:
> On Aug  3 10:00, Christopher Faylor wrote:
> > 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.
> 
> Is git-svn using perl?  I have constant problems using perl after a 
> rebase.  The problem starts with perl.exe(!) being rebased(!) to
> 0x50000000(!).  However, when rebasing perl.exe to 0x400000 where it

Well, not exactly 0x50000000, but in that region.


Corinna

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

perl.exe has wrong base address (was Re: git-svn hang starting with 20110721 snapshot.)

[Christopher Faylor]

On Wed, Aug 03, 2011 at 04:56:05PM +0200, Corinna Vinschen wrote:
>Is git-svn using perl?

Yes, very heavily.  Setting CYGWIN_DEBUG=perl filled my screen with gdb
windows.

>I have constant problems using perl after a rebase.  The problem starts
>with perl.exe(!) being rebased(!) to 0x50000000(!).

So, it is.  How odd.

>However, when rebasing perl.exe to 0x400000 where it belongs, it
>doesn't work either.  Only reinstalling perl helped afterwards.

perl itself seems to still work but rebasing doesn't solve the hang.

>Reini, could you please update the perl package so that the executable
>is in its default place at 0x400000?

Or at least explain why it's sitting up there where it interferes with
dlls?

cgf

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

Re: git-svn hang starting with 20110721 snapshot.

[Christopher Faylor]

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?

cgf

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

Re: git-svn hang starting with 20110721 snapshot.

[David Rothenberger]

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

Re: git-svn hang starting with 20110721 snapshot.

[Corinna Vinschen]

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

Re: git-svn hang starting with 20110721 snapshot.

[Yaakov (Cygwin/X)]

On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote:
> 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.

At this moment, I've got DLLs from 0xf0000000 all the way down to
0xa1740000, and I could easily have more if I installed all of KDE
(which I provide in Ports, but I prefer to use GNOME).  So where do you
suggest I find that kind of open space in the lower half?


Yaakov



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

Re: git-svn hang starting with 20110721 snapshot.

[Corinna Vinschen]

On Aug  3 15:02, Yaakov (Cygwin/X) wrote:
> On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote:
> > 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.
> 
> At this moment, I've got DLLs from 0xf0000000 all the way down to
> 0xa1740000, and I could easily have more if I installed all of KDE
> (which I provide in Ports, but I prefer to use GNOME).  So where do you
> suggest I find that kind of open space in the lower half?

Did you use the current rebaseall?  If so you have a 64K hole between
each DLL.  Other than that I don't have an answer for you.  There's only
so much you can do within the 32 bit address space.  That's only one
reason why a 64 bit Cygwin would be a good idea.


Corinna

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

Re: git-svn hang starting with 20110721 snapshot.

[Corinna Vinschen]

On Aug  3 22:19, Corinna Vinschen wrote:
> On Aug  3 15:02, Yaakov (Cygwin/X) wrote:
> > On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote:
> > > 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.
> > 
> > At this moment, I've got DLLs from 0xf0000000 all the way down to
> > 0xa1740000, and I could easily have more if I installed all of KDE
> > (which I provide in Ports, but I prefer to use GNOME).  So where do you
> > suggest I find that kind of open space in the lower half?
> 
> Did you use the current rebaseall?  If so you have a 64K hole between
> each DLL.  Other than that I don't have an answer for you.  There's only
> so much you can do within the 32 bit address space.  That's only one
> reason why a 64 bit Cygwin would be a good idea.

Of course there are other answers, but their implementation is really
tricky:

- Analyze all executables and rebase DLLs which are not used together
  in the same executable to the same addresses.  Not good for runtime
  loading.

- Replace the Windows loader with your own loader in Cygwin.  You'll
  never have to rebase again.


Corinna

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

Re: git-svn hang starting with 20110721 snapshot.

[David Rothenberger]

On 8/3/2011 1:19 PM, Corinna Vinschen wrote:
> On Aug  3 15:02, Yaakov (Cygwin/X) wrote:
>> On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote:
>>> 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.
>>
>> At this moment, I've got DLLs from 0xf0000000 all the way down to
>> 0xa1740000, and I could easily have more if I installed all of KDE
>> (which I provide in Ports, but I prefer to use GNOME).  So where do you
>> suggest I find that kind of open space in the lower half?
> 
> Did you use the current rebaseall?  If so you have a 64K hole between
> each DLL.

Isn't this avoided by passing "-o 0" to the current rebaseall?

> Other than that I don't have an answer for you.  There's only
> so much you can do within the 32 bit address space.  That's only one
> reason why a 64 bit Cygwin would be a good idea.

What was the motivation for putting the heap and mmaps above 0x80000000?
Was there not enough space for them below? Would there be enough space
below if all the DLLs were above?

-- 
David Rothenberger  ----  daveroth@acm.org

zeal, n.:
        Quality seen in new graduates -- if you're quick.

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

Re: git-svn hang starting with 20110721 snapshot.

[David Rothenberger]

On 8/3/2011 1:32 PM, David Rothenberger wrote:
> On 8/3/2011 1:19 PM, Corinna Vinschen wrote:
>> Other than that I don't have an answer for you.  There's only
>> so much you can do within the 32 bit address space.  That's only one
>> reason why a 64 bit Cygwin would be a good idea.
> 
> What was the motivation for putting the heap and mmaps above 0x80000000?
> Was there not enough space for them below? Would there be enough space
> below if all the DLLs were above?

Rereading this, I realized it sounds a little snotty. I'm not trying to
second guess your decision; I was just curious. Feel free to ignore the
question. :)

-- 
David Rothenberger  ----  daveroth@acm.org

Warning: Listening to WXRT on April Fools' Day is not recommended for
those who are slightly disoriented the first few hours after waking up.
                -- Chicago Reader 4/22/83

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

Re: perl.exe has wrong base address (was Re: git-svn hang starting with 20110721 snapshot.)

[Reini Urban]

2011/8/3 Christopher Faylor:
> On Wed, Aug 03, 2011 at 04:56:05PM +0200, Corinna Vinschen wrote:
>>Is git-svn using perl?
>
> Yes, very heavily.  Setting CYGWIN_DEBUG=perl filled my screen with gdb
> windows.
>
>>I have constant problems using perl after a rebase.  The problem starts
>>with perl.exe(!) being rebased(!) to 0x50000000(!).
>
> So, it is.  How odd.
>
>>However, when rebasing perl.exe to 0x400000 where it belongs, it
>>doesn't work either.  Only reinstalling perl helped afterwards.
>
> perl itself seems to still work but rebasing doesn't solve the hang.
>
>>Reini, could you please update the perl package so that the executable
>>is in its default place at 0x400000?
>
> Or at least explain why it's sitting up there where it interferes with
> dlls?

That is an error in my perlrebase script. Locally I already fixed it.
I'll also rewrite it to use rebase -s with our user-installed site_perl dll's.

Now that rebase 3.0.2 is almost ready I'll roll a perl-5.14.1-1 after that.
-- 
Reini

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

Re: git-svn hang starting with 20110721 snapshot.

[Corinna Vinschen]

On Aug  3 13:32, David Rothenberger wrote:
> On 8/3/2011 1:19 PM, Corinna Vinschen wrote:
> > On Aug  3 15:02, Yaakov (Cygwin/X) wrote:
> >> On Wed, 2011-08-03 at 21:03 +0200, Corinna Vinschen wrote:
> >>> 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.
> >>
> >> At this moment, I've got DLLs from 0xf0000000 all the way down to
> >> 0xa1740000, and I could easily have more if I installed all of KDE
> >> (which I provide in Ports, but I prefer to use GNOME).  So where do you
> >> suggest I find that kind of open space in the lower half?
> > 
> > Did you use the current rebaseall?  If so you have a 64K hole between
> > each DLL.
> 
> Isn't this avoided by passing "-o 0" to the current rebaseall?

Yes, but you have to think about it every time you start rebaseall.

> > Other than that I don't have an answer for you.  There's only
> > so much you can do within the 32 bit address space.  That's only one
> > reason why a 64 bit Cygwin would be a good idea.
> 
> What was the motivation for putting the heap and mmaps above 0x80000000?
> Was there not enough space for them below? Would there be enough space
> below if all the DLLs were above?

It's much easier.  For once, we can't rebase the DLLs into the large 
address area in the distro because it only works on systems supporting
large addresses.  It also requires that all executables have the large
address awareness flag set, which is not default either so far, so there's
a pretty high probability the next update breaks your installation again
and you have to run rebaseall *and* peflagsall with the right flags to
fix it.

Mmaps are using a top-down algorithm anyway, so they are automatically
in the large address area, even in 1.7.9.  So there was only the heap,
which typically uses 384 Megs and needs space to grow for big apps
and lots of sbrk calls.  Therefore, IMO, the large address area is the
ideal space for the heap.


Corinna

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

Re: git-svn hang starting with 20110721 snapshot.

[Corinna Vinschen]

On Aug  3 13:42, David Rothenberger wrote:
> On 8/3/2011 1:32 PM, David Rothenberger wrote:
> > On 8/3/2011 1:19 PM, Corinna Vinschen wrote:
> >> Other than that I don't have an answer for you.  There's only
> >> so much you can do within the 32 bit address space.  That's only one
> >> reason why a 64 bit Cygwin would be a good idea.
> > 
> > What was the motivation for putting the heap and mmaps above 0x80000000?
> > Was there not enough space for them below? Would there be enough space
> > below if all the DLLs were above?
> 
> Rereading this, I realized it sounds a little snotty. I'm not trying to
> second guess your decision; I was just curious. Feel free to ignore the
> question. :)

Naah, never mind.


Corinna

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