X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 6 May 2010 17:46:02 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: 1.7.5-1: execv fails in .exe compiled Message-ID: <20100506154602.GY1845@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <20100506151924 DOT GX1845 AT calimero DOT vinschen DOT de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20100506151924.GX1845@calimero.vinschen.de> User-Agent: Mutt/1.5.20 (2009-06-14) 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 May 6 17:19, Corinna Vinschen wrote: > On May 6 10:21, Stephen Morton wrote: > > We have a gcc 3.4.6 cross-compiler that is an essential part of our > > development environment that does not work under cygwin 1.7 > > (+Win7-64). Somehow cc.exe is not able to execv cc1.exe. > > > > I'm stumped and any insight you can give me would be much appreciated. > > > > Note: the fact that the program that is failing is a compiler might > > cause some confusion. The cygwin gcc is not failing. What's failing > > (failing to execv a sub-program) is just a tool that I'm running that > > just happens to be a compiler. > > Unfortunately the information you're giving isn't enough to figure out > what happens. This is the interesting snippet in the strace output: > > > 152 114745 [main] cc386 2960 mount_info::conv_to_win32_path: > > conv_to_win32_path (/usr/local/companytools/gcc34/x86/cc1.exe) > > 157 114902 [main] cc386 2960 set_flags: flags: binary (0x2) > > --- Process 2960, exception C0000005 at 6110721F > > 296 115198 [main] cc386 2960 exception::handle: In > > cygwin_except_handler exc 0xC0000005 at 0x6110721F sp 0x28A2DC > > So we know there's a SEGV at address 0x6110721F, which is inside the > memcpy function in 1.7.5, and it has been called from within a Cygwin > function. The Cygwin function mount_info::conv_to_win32_path is called > very often in fact, so this seems to be an unlikely border case. > > This doesn't tell us much about the root cause. Apparently > cc386 supresses core dumps (or rather, stackdumps in our case). If > there's a call to setrlimit (RLIMIT_CORE, ...), it would make sense > to disable this and try to create a stackdump. > > What you also could try is to install the Cygwin sources and then use > the CYGWIN=error_start facility to start GDB when the error occurs, see > http://cygwin.com/cygwin-ug-net/using-cygwinenv.html Oh, btw., did you try the latest developer snapshot from http://cygwin.com/snapshots/ ? There's always the chance this problem is fixed in CVS. 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