X-Recipient: archive-cygwin@delorie.com X-SWARE-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_THEBAT,KHOP_THREADED,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Date: Fri, 23 Nov 2012 16:32:58 +0400 From: Andrey Repin Reply-To: Andrey Repin Message-ID: <1429797465.20121123163258@mtu-net.ru> To: Corinna Vinschen Subject: Re: git fork failure on pull with a workaround (hopefully a clue for a fix) In-Reply-To: <20121123114127.GO17347@calimero.vinschen.de> References: <509AB02F.1000300@kitware.com> <509AC4E0.2080709@bopp.net> <509BC18E.1050905@kitware.com> <20121123114127.GO17347@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Greetings, Corinna Vinschen! >> >>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. Would it be meaningful to instrument this cause for easier tracking? -- WBR, Andrey Repin (anrdaemon@freemail.ru) 23.11.2012, <16:31> Sorry for my terrible english... -- 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