Re: 1.7.5-1: execv fails in .exe compiled]

[Stan]

Stephen Morton said:
>
 
>
>  109  225019 [main] cc386 1312 spawnve: spawnve
>(/usr/local/companytools/gcc34/x86/cc1.exe,
>/usr/local/companytools/gcc34/x86/cc1.exe, 1002DAA0)

The /usr/local/companytools part sure sounds like a local (non-cygwin)
app. Have you tried cygcheck?


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

Re: 1.7.5-1: execv fails in .exe compiled

[Stephen Morton]

On Thu, 13 May 2010 17:49:08 -0400, Larry Hall wrote:
>On 5/13/2010 5:45 PM, Stephen Morton wrote:
>>The problem appears to be cygwin 1.7-specific. (*)
>>
>>I get a stackdump as follows. I find that I get a stackdump under a
>>cygwin shell (DOS terminal) but not under mintty so I'm not 100% sure
>>the stackdump is for the correct error.
>
>Do you have a ?

http://cygwin.com/acronyms/#WADR , this was in my _very_first_email_
   "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."

I do have a binary --an only slightly modified gcc 3.4.6 cross-compiler--
that always fails. And there is a simple testcase that fails with that
binary. But I doubt that really does anybody any good.

For now, my team will continue our prototyping on Win7 + Cygwin 1.5.
We'll re-evaluate when cygwin 1.7 seems a bit more mature (less frequent
updates with fixes to less severe-sounding problems). I know this isn't
a particularly recommended configuration, but it seems to be working.

Stephen

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

Re: 1.7.5-1: execv fails in .exe compiled

[Stephen Morton]

It looks like the stackdumps I sent may be due to secondary crashes.
Here is the strace of a failure with the segfault and crashdump. It is
different than the strace I sent earlier.

   88  224700 [sig] cc386 356 wait_sig: signalling pack.wakeup 0x6B0
 2290  224775 [main] cc386 1312 wait_for_sigthread: wait_sig_inited 0x7EC
  117  224817 [main] cc386 356 sig_send: returning 0x0 from sending signal -34
   67  224842 [main] cc386 1312 wait_for_sigthread: process/signal
handling enabled, state 0x41
   55  224872 [main] cc386 356 wait4: calling proc_subproc, pid 1312, options 0
   68  224910 [main] cc386 1312 fork: 0 = fork()
   91  224963 [main] cc386 356 proc_subproc: args: 4, 2284288
  109  225019 [main] cc386 1312 spawnve: spawnve
(/usr/local/companytools/gcc34/x86/cc1.exe,
/usr/local/companytools/gcc34/x86/cc1.exe, 1002DAA0)
   80  225043 [main] cc386 356 proc_subproc: wval->pid 1312, wval->options 0
   83  225102 [main] cc386 1312 spawn_guts: spawn_guts (3,
/usr/local/companytools/gcc34/x86/cc1.exe)
  106  225149 [main] cc386 356 checkstate: nprocs 1
  106  225208 [main] cc386 1312 perhaps_suffix: prog
'/usr/local/companytools/gcc34/x86/cc1.exe'
   84  225233 [main] cc386 356 stopped_or_terminated: considering pid 1312
   77  225285 [main] cc386 1312 normalize_posix_path: src
/usr/local/companytools/gcc34/x86/cc1.exe
   74  225307 [main] cc386 356 checkstate: no matching terminated children found
  104  225389 [main] cc386 1312 normalize_posix_path:
/usr/local/companytools/gcc34/x86/cc1.exe = normalize_posix_path
(/usr/local/companytools/gcc34/x86/cc1.exe)
  107  225414 [main] cc386 356 checkstate: returning -1
   90  225479 [main] cc386 1312 mount_info::conv_to_win32_path:
conv_to_win32_path (/usr/local/companytools/gcc34/x86/cc1.exe)
   77  225491 [main] cc386 356 proc_subproc: only found non-terminated children
   91  225582 [main] cc386 356 proc_subproc: finished processing
terminated/stopped child
  108  225587 [main] cc386 1312 set_flags: flags: binary (0x2)
--- Process 1312, exception C005 at 6110721F
  237  225819 [main] cc386 356 proc_subproc: returning 1
  335  225922 [main] cc386 1312 exception::handle: In
cygwin_except_handler exc 0xC005 at 0x6110721F sp 0x22A2FC
  116  226038 [main] cc386 1312 exception::handle: In
cygwin_except_handler sig 11 at 0x6110721F
   82  226120 [main] cc386 1312 exception::handle: In
cygwin_except_handler calling 0x0
   78  226198 [main] cc386 1312 perhaps_suffix: buf (null), suffix
found '(null)'
  156  226354 [main] cc386 1312 __set_errno: int spawn_guts(const
char*, const char* const*, const char* const*, int, int, int):369 val
2
  771  227125 [main] cc386 1312 fhandler_console::write: 10029448, 5
   87  227212 [main] cc386 1312 fhandler_console::write: at 99(c) state is 0
--- Process 1312, exception C005 at 611131D8
  181  227393 [main] cc386 1312 exception::handle: In
cygwin_except_handler exc 0xC005 at 0x611131D8 sp 0x22B950
  108  227501 [main] cc386 1312 exception::handle: In
cygwin_except_handler sig 11 at 0x611131D8
   87  227588 [main] cc386 1312 exception::handle: In
cygwin_except_handler calling 0x0
   73  227661 [main] cc386 1312 try_to_debug: debugger_command ''
  604  228265 [main] cc386 1312 open_stackdumpfile: Dumping stack
trace to cc386.exe.stackdump
35179  263444 [main] cc386 1312 _cygtls::inside_kernel: pc 0x611131D8,
h 0x6100, inside_kernel 0
  189  263633 [main] cc386 1312 normalize_posix_path: src /dev/kmsg
  100  263733 [main] cc386 1312 normalize_posix_path: /dev/kmsg =
normalize_posix_path (/dev/kmsg)
   91  263824 [main] cc386 1312 mount_info::conv_to_win32_path:
conv_to_win32_path (/dev/kmsg)
--- Process 1312, exception C005 at 61109620
  217  264041 [main] cc386 1312 exception::handle: In
cygwin_except_handler exc 0xC005 at 0x61109620 sp 0x229830
   88  264129 [main] cc386 1312 exception::handle: In
cygwin_except_handler sig 11 at 0x61109620
   73  264202 [main] cc386 1312 exception::handle: In
cygwin_except_handler calling 0x0
   96  264298 [main] cc386 1312 __set_errno: fhandler_base*
build_fh_name(const char*, unsigned int, suffix_info*):410 val 14
  225  264523 [main] cc386 1312 try_to_debug: debugger_command ''
   97  264620 [main] cc386 1312 _cygtls::signal_exit: about to call do_exit (8B)
   79  264699 [main] cc386 1312 do_exit: do_exit (139), exit_state 2
   85  264784 [main] cc386 1312 void: 0x0 = signal (20, 0x1)
  219  265003 [main] cc386 1312 void: 0x40E880 = signal (1, 0x1)
   89  265092 [main] cc386 1312 void: 0x40E880 = signal (2, 0x1)
   81  265173 [main] cc386 1312 void: 0x0 = signal (3, 0x1)

Stephen


On Thu, May 13, 2010 at 5:45 PM, Stephen Morton
 wrote:
> The problem appears to be cygwin 1.7-specific. (*)
>
> I get a stackdump as follows. I find that I get a stackdump under a
> cygwin shell (DOS terminal) but not under mintty so I'm not 100% sure
> the stackdump is for the correct error.
>
> Exception: STATUS_ACCESS_VIOLATION at eip=611131D8
> eax=0022B9E4 ebx=7FF70008 ecx=0063 edx

Re: 1.7.5-1: execv fails in .exe compiled

[Larry Hall (Cygwin)]

On 5/13/2010 5:45 PM, Stephen Morton wrote:

The problem appears to be cygwin 1.7-specific. (*)

I get a stackdump as follows. I find that I get a stackdump under a
cygwin shell (DOS terminal) but not under mintty so I'm not 100% sure
the stackdump is for the correct error.


Do you have a ?

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


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

Re: 1.7.5-1: execv fails in .exe compiled

[Stephen Morton]

The problem appears to be cygwin 1.7-specific. (*)

I get a stackdump as follows. I find that I get a stackdump under a
cygwin shell (DOS terminal) but not under mintty so I'm not 100% sure
the stackdump is for the correct error.

Exception: STATUS_ACCESS_VIOLATION at eip=611131D8
eax=0022B9E4 ebx=7FF70008 ecx=0063 edx=0022B9E4 esi=0001 edi=0005
ebp=0022B998 esp=0022B950
program=C:\usr\local\companytools\gcc34\x86\cc386.exe, pid 1312,
thread main
cs=001B ds=0023 es=0023 fs=003B gs= ss=0023
Stack trace:
Frame Function  Args
0022B998  611131D8  (0022D000, 7FF70008, 10029448, 0005)
0022B9F8  610C953E  (8000, 10029448, 0005, 0001)
1002944D  6103413C  (6800, 46611C2F, 68DF0DF0, 00100280)
End of stack trace

I was able to get a further stack trace from gdb from that. Again, it
would only happen on a cygwin shell and not mintty so I'm not sure I
copied the correct error:
(gdb) backtrace
#0  0x7c90120f in ?? ()
#1  0x7c951e68 in ?? ()
#2  0x0005 in ?? ()
#3  0x0004 in ?? ()
#4  0x0001 in ?? ()
#5  0x006dffd0 in ?? ()
#6  0x0246 in ?? ()
#7  0x in ?? ()
#8  0x7c90e920 in ?? ()
#9  0x7c951e88 in ?? ()
#10 0x in ?? ()

Stephen

(*) I know that doesn't mean that it's 1.7's fault. Perhaps the
problem was pre-existing and was only revealed in 1.7. But it works in
1.3 and 1.5 on WinXP and fails in 1.7 in WinXP-32, Vista-32, Win7-67.

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

Re: 1.7.5-1: execv fails in .exe compiled

[Stephen Morton]

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 C005 at 6110721F
>>   296  115198 [main] cc386 2960 exception::handle: In
>> cygwin_except_handler exc 0xC005 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

Re: 1.7.5-1: execv fails in .exe compiled

[Corinna Vinschen]

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 C005 at 6110721F
> >   296  115198 [main] cc386 2960 exception::handle: In
> > cygwin_except_handler exc 0xC005 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

Re: 1.7.5-1: execv fails in .exe compiled

[Corinna Vinschen]

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 C005 at 6110721F
>   296  115198 [main] cc386 2960 exception::handle: In
> cygwin_except_handler exc 0xC005 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