X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 6 May 2010 17:19:24 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: 1.7.5-1: execv fails in .exe compiled Message-ID: <20100506151924.GX1845@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 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 > 8. The code that's failing is in gcc-3.4.6/libiberty/pex-unix.c > >  int (*func)() = (flags & PEXECUTE_SEARCH ? execvp : execv); > >  ... fork a child task ... > >  (program is "/usr/local/companytools/gcc34/x86/cc1.exe") > >      (*func) (program, argv); > >      /* Should never reach here because have execv-ed program >         but it does. This does not mean that the child had a non-zero >         exit code, it means that the execv failed to work. >       */ > >      fprintf (stderr, "%s: ", this_pname); >      fprintf (stderr, install_error_msg, program); >      fprintf (stderr, " %s\n", errno, xstrerror (errno)); >      exit (-1); > > 9. I have tried making a dummy program that's just a wrapper for the failing >   code and passing in all the same data as the failing case. And it > works. That really confuses me. Yeah, it's not clear if that's actually a bug in Cygwin or maybe a bug in cc386, which just didn't have fatal consequences on older Cygwin versions. It would be most helpful if you would create debug versions of your compiler tools and the Cygwin DLL and debug the situation using GDB. 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