X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Fri, 23 Nov 2012 12:41:27 +0100 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: git fork failure on pull with a workaround (hopefully a clue for a fix) Message-ID: <20121123114127.GO17347@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <509AB02F DOT 1000300 AT kitware DOT com> <509AC4E0 DOT 2080709 AT bopp DOT net> <509BC18E DOT 1050905 AT kitware DOT com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <509BC18E.1050905@kitware.com> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list 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