Mail Archives: cygwin/2010/05/06/11:19:45
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
- Raw text -