MIME-Version: 1.0
Date: Fri, 7 May 2010 12:00:22 -0400
Message-ID: <AANLkTinTTqUHMjCXisfzcYRlK2TI2kDX9d5AgZBOME9R@mail.gmail.com>
Subject: Re: 1.7.5-1: execv fails in .exe compiled
From: Stephen Morton <stephen DOT c DOT morton AT gmail DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=ISO-8859-1
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Thanks for your suggestions Corinna. My update is below.

On Thu, 6 May 2010 17:19:24 +0200 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

I was able to try both of these things, unfortunately with little success.

I modified the problem code to specifically setrlimit(RLIMIT_CORE,...) to the
maximum value (obtained by getrlimit() and checking for error codes along the
way) and got no stack dump and no gdb attempt. That would indicate to me that
I'd just done things wrong but... initially I had an error in my debug code
where I was trying to print an integer as a %s. It caused a crash
(unsurprisingly) but it also generated a stack dump and tried to launch gdb
(gdb failed to launch, but the interesting thing was that it tried). So
somehow I've got an execv failing, and I've got a cygwin exception. But not
enough of a failure to cause the OS to stack dump or try to launch gdb. That
must mean something.

I also updated to the latest cygwin snapshot (At least, I took the
cygwin-inst-20100506.tar.bz2 and copied its contents over /etc and /usr. I
hope that's how one does it.) and the problem persisted.

My plans now are:
1. Try to use gdb to narrow down what memcpy is failing. Any tips on that
   would be appreciated.
2. Also, trying Cygwin 1.7 on Windows XP would also be a useful test.
3. Any other suggestions?


Regards,
Stephen Morton

--
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