Re: git fork failure on pull with a workaround (hopefully a clue for a fix)

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Nov  8 09:28, Bill Hoffman wrote:
> On 11/7/2012 3:30 PM, Jeremy Bopp wrote:
> >On 11/07/2012 01:02 PM, Bill Hoffman wrote:
> >>Is there a
> >>way to debug this?
> >
> >The first step is to follow the problem reporting guidelines:
> >
> >   http://cygwin.com/problems.html
> >
> >Following them may reveal a conflicting cygwin.dll file or something
> >similar in your full path which is interfering with some git subcommand
> >loading properly.
> 
> Attached is the cygcheck.out.
> 
> >
> >Given that a PATH of just /usr/bin works for you, try appending
> >progressively more segments of your original path until the problem
> >reproduces.  Once you find a PATH that reliably fails, remove the last
> >added segment as a suspect and continue adding the remaining segments
> >from the original PATH until you are left with a good PATH and a list of
> >suspects.  Then go back to the PATH of /usr/bin and append each suspect
> >individually and test again to see if the suspects are the problem alone.
> >
> 
> I had done that in the past and found that it seemed to be a length
> issue.  I could not find a specific thing that needed to be in the
> PATH to make it break.  I just tried again, and here is what I
> found:
> 
> This fails:  (length 372)
> 
> export PATH="/usr/bin:/cygdrive/c/Program Files (x86)/Microsoft
> Visual Studio 9.0/Common7/IDE:/cygdrive/c/Program Files
> (x86)/Microsoft Visual Studio 9.0/VC/BIN:/cygdrive/c/Program Files
> (x86)/Microsoft Visual Studio 9.0/Common7/Tools:/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5:/cygdrive/c/Windows/Microsoft.NET/Framework/v2.0.50727:/usr/local/bin:/usr/bin:/some/bogus/path/that"
> 
> 
> But this works:  (length 371)
> 
> export PATH="/usr/bin:/cygdrive/c/Program Files (x86)/Microsoft
> Visual Studio 9.0/Common7/IDE:/cygdrive/c/Program Files
> (x86)/Microsoft Visual Studio 9.0/VC/BIN:/cygdrive/c/Program Files
> (x86)/Microsoft Visual Studio 9.0/Common7/Tools:/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5:/cygdrive/c/Windows/Microsoft.NET/Framework/v2.0.50727:/usr/local/bin:/usr/bin:/some/bogus/path/tha"
> 
> 
> However, it is not just length....
> 
> Because this one works:  (length 400)

I *think* this is an issue between Windows and Cygwin for which there's
no easy solution.  The memory layout created by Windows can move the
main stack address in a child process depending on the size of the
environment.

I observed this myself, but didn't find a way to fix it.  Maybe it's
related to the fact that Cygwin cleans out the Windows environment to a
bare minimum when forking.  This obviously results in a changed env.


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