* git-svn hang starting with 20110721 snapshot. @ 2011-08-02 17:59 David Rothenberger 2011-08-03 8:45 ` Corinna Vinschen 0 siblings, 1 reply; 18+ messages in thread From: David Rothenberger @ 2011-08-02 17:59 UTC (permalink / raw) To: cygwin [-- 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-02 17:59 git-svn hang starting with 20110721 snapshot David Rothenberger @ 2011-08-03 8:45 ` Corinna Vinschen 2011-08-03 13:46 ` Christopher Faylor 0 siblings, 1 reply; 18+ messages in thread From: Corinna Vinschen @ 2011-08-03 8:45 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 8:45 ` Corinna Vinschen @ 2011-08-03 13:46 ` Christopher Faylor 2011-08-03 14:00 ` Christopher Faylor 0 siblings, 1 reply; 18+ messages in thread From: Christopher Faylor @ 2011-08-03 13:46 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 13:46 ` Christopher Faylor @ 2011-08-03 14:00 ` Christopher Faylor 2011-08-03 14:56 ` Corinna Vinschen 2011-08-03 18:03 ` git-svn hang starting with 20110721 snapshot Christopher Faylor 0 siblings, 2 replies; 18+ messages in thread From: Christopher Faylor @ 2011-08-03 14:00 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 14:00 ` Christopher Faylor @ 2011-08-03 14:56 ` Corinna Vinschen 2011-08-03 15:01 ` Corinna Vinschen 2011-08-03 15:15 ` perl.exe has wrong base address (was Re: git-svn hang starting with 20110721 snapshot.) Christopher Faylor 2011-08-03 18:03 ` git-svn hang starting with 20110721 snapshot Christopher Faylor 1 sibling, 2 replies; 18+ messages in thread From: Corinna Vinschen @ 2011-08-03 14:56 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 14:56 ` Corinna Vinschen @ 2011-08-03 15:01 ` Corinna Vinschen 2011-08-03 15:15 ` perl.exe has wrong base address (was Re: git-svn hang starting with 20110721 snapshot.) Christopher Faylor 1 sibling, 0 replies; 18+ messages in thread From: Corinna Vinschen @ 2011-08-03 15:01 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* perl.exe has wrong base address (was Re: git-svn hang starting with 20110721 snapshot.) 2011-08-03 14:56 ` Corinna Vinschen 2011-08-03 15:01 ` Corinna Vinschen @ 2011-08-03 15:15 ` Christopher Faylor 2011-08-04 7:07 ` Reini Urban 1 sibling, 1 reply; 18+ messages in thread From: Christopher Faylor @ 2011-08-03 15:15 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: perl.exe has wrong base address (was Re: git-svn hang starting with 20110721 snapshot.) 2011-08-03 15:15 ` perl.exe has wrong base address (was Re: git-svn hang starting with 20110721 snapshot.) Christopher Faylor @ 2011-08-04 7:07 ` Reini Urban 0 siblings, 0 replies; 18+ messages in thread From: Reini Urban @ 2011-08-04 7:07 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 14:00 ` Christopher Faylor 2011-08-03 14:56 ` Corinna Vinschen @ 2011-08-03 18:03 ` Christopher Faylor 2011-08-03 18:40 ` David Rothenberger 1 sibling, 1 reply; 18+ messages in thread From: Christopher Faylor @ 2011-08-03 18:03 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 18:03 ` git-svn hang starting with 20110721 snapshot Christopher Faylor @ 2011-08-03 18:40 ` David Rothenberger 2011-08-03 19:03 ` Corinna Vinschen 0 siblings, 1 reply; 18+ messages in thread From: David Rothenberger @ 2011-08-03 18:40 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 18:40 ` David Rothenberger @ 2011-08-03 19:03 ` Corinna Vinschen 2011-08-03 20:02 ` Yaakov (Cygwin/X) 0 siblings, 1 reply; 18+ messages in thread From: Corinna Vinschen @ 2011-08-03 19:03 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 19:03 ` Corinna Vinschen @ 2011-08-03 20:02 ` Yaakov (Cygwin/X) 2011-08-03 20:20 ` Corinna Vinschen 0 siblings, 1 reply; 18+ messages in thread From: Yaakov (Cygwin/X) @ 2011-08-03 20:02 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 20:02 ` Yaakov (Cygwin/X) @ 2011-08-03 20:20 ` Corinna Vinschen 2011-08-03 20:26 ` Corinna Vinschen 2011-08-03 20:33 ` David Rothenberger 0 siblings, 2 replies; 18+ messages in thread From: Corinna Vinschen @ 2011-08-03 20:20 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 20:20 ` Corinna Vinschen @ 2011-08-03 20:26 ` Corinna Vinschen 2011-08-03 20:33 ` David Rothenberger 1 sibling, 0 replies; 18+ messages in thread From: Corinna Vinschen @ 2011-08-03 20:26 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 20:20 ` Corinna Vinschen 2011-08-03 20:26 ` Corinna Vinschen @ 2011-08-03 20:33 ` David Rothenberger 2011-08-03 20:43 ` David Rothenberger 2011-08-04 8:29 ` Corinna Vinschen 1 sibling, 2 replies; 18+ messages in thread From: David Rothenberger @ 2011-08-03 20:33 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 20:33 ` David Rothenberger @ 2011-08-03 20:43 ` David Rothenberger 2011-08-04 8:29 ` Corinna Vinschen 2011-08-04 8:29 ` Corinna Vinschen 1 sibling, 1 reply; 18+ messages in thread From: David Rothenberger @ 2011-08-03 20:43 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 20:43 ` David Rothenberger @ 2011-08-04 8:29 ` Corinna Vinschen 0 siblings, 0 replies; 18+ messages in thread From: Corinna Vinschen @ 2011-08-04 8:29 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: git-svn hang starting with 20110721 snapshot. 2011-08-03 20:33 ` David Rothenberger 2011-08-03 20:43 ` David Rothenberger @ 2011-08-04 8:29 ` Corinna Vinschen 1 sibling, 0 replies; 18+ messages in thread From: Corinna Vinschen @ 2011-08-04 8:29 UTC (permalink / raw) To: cygwin 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-08-04 8:29 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-02 17:59 git-svn hang starting with 20110721 snapshot David Rothenberger 2011-08-03 8:45 ` Corinna Vinschen 2011-08-03 13:46 ` Christopher Faylor 2011-08-03 14:00 ` Christopher Faylor 2011-08-03 14:56 ` Corinna Vinschen 2011-08-03 15:01 ` Corinna Vinschen 2011-08-03 15:15 ` perl.exe has wrong base address (was Re: git-svn hang starting with 20110721 snapshot.) Christopher Faylor 2011-08-04 7:07 ` Reini Urban 2011-08-03 18:03 ` git-svn hang starting with 20110721 snapshot Christopher Faylor 2011-08-03 18:40 ` David Rothenberger 2011-08-03 19:03 ` Corinna Vinschen 2011-08-03 20:02 ` Yaakov (Cygwin/X) 2011-08-03 20:20 ` Corinna Vinschen 2011-08-03 20:26 ` Corinna Vinschen 2011-08-03 20:33 ` David Rothenberger 2011-08-03 20:43 ` David Rothenberger 2011-08-04 8:29 ` Corinna Vinschen 2011-08-04 8:29 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).