Re: WINDOWS32 "Signal 127" due to a path in quotes bug

[J. Grant]

Hi,

> > >> I could not replicate the "Signal 127" message, I could replicate "Error
> > >> 127", maybe the different win32 build options effect this in a way that
> > >> it is incorrectly named as a "Signal" 127 error.
> > > 
> > > All I can say is that I cannot reproduce even the "Error 127" message
> > > with the MinGW build of GNU Make 3.81 beta3.  I get "Error 2", which
> > > is entirely reasonable (it's the Windows code for "file not found").
> >
> > Did you run with -j8?
>
> Both with and without it, with identical results.

Are you using MSYS /bin/sh.exe, GNU bash v2.04 ?

[...]
> It didn't fail to exec, it simply didn't find the file it was supposed
> to run: c:/quote_path.exe does not exist on my machine.  (Does it exist
> on yours?  How about the other file, c:/working_test_without_quotes.exe?)

I have tried with all four cases, it does not appear to make a difference.
Using 3.80 I experienced the "Signal 127" if I remember correctly. I've not
been able to replicated it either.

I ran through some signal tests, see the end of this email for the details
of a problem.

> My Posix references seem to say that the shell must return 127 in this
> case, so Bash behaves correctly while zsh does not.  But that's not a
> Make issue.

Agreed. Thanks for taking the time to go through this with me.


1) Testing on Debian GNU/Linux

$ make -f makefile_sig.mak -j8
<snip>
15299
15300
make: *** [temp1] Interrupt
make: *** [temp2] Interrupt


MSYS, with MSVC build:

make -f makefile_sig.mak -j8

15299
15300

rxvt.exe
   sh.exe
     make.exe
        main.exe
        main.exe

Pressing <ctrl> + C kills make.exe.  So main.exe and main.exe continue
on their own, sh and rxvt are broken, and have to be killed and restarted.

would it be expected that the <ctrl>+c signal would not be passed to the
launched process?


I change the program to just count to 4 Billion, <ctrl>+C did not kill
the rxvt/sh.exe of MSYS, it did kill make.exe on MSVC build testing
under MSYS, i just got the final text from the main.exe which was still
running output on the terminal about 10 secs later..
(the attatched file does not print the current count, like the first few
tests above)



Also, could the GNU/Linux "Interrupt" description be expanded upon?

Perhaps:

"<ctrl>+C Interrupt received"



2) Using todays CVS source on an MSCV build I experienced this:

C:\msys\1.0\home\now3d>make -f makefile_sig.mak -j2
main
main
counting:
counting:
make: *** [temp1] Error -1073741510make:
*** [temp2] Error -1073741510


Is the odd exit value just because my simple C test program does not
handle <ctrl>+C ? So make displays some uninitialised value which would
have been overwritten with 0 had my program returned etc?



address@hidden now3d]$ make -f makefile_sig.mak -j8
./main
counting:
./main
counting:
make: *** [temp1] Interrupt
make: *** [temp2] Interrupt


this is not displayed on win32 because exit_sig == 0

This is what returns TRUE, getting the odd value.
        GetExitCodeResult = GetExitCodeProcess(childhand,
(DWORD*)&pproc->exit_code);
        if (GetExitCodeResult == FALSE) {
                pproc->last_err = GetLastError();
                pproc->lerrno = E_SCALL;
        }

The output got it from here:

/* keep track of children so we can implement a waitpid-like routine */
static sub_process *proc_array[256];



in w32/subproc/sub_proc.c:183


process_exit_code(HANDLE proc)
{
        return (((sub_process *)proc)->exit_code);
}

This is the struct it after casting, some of it is zero, so it is
difficult to know if any of it is valid:


-       (sub_process *)proc     0x00885cf0 {sv_stdin=0x00885cf0
sv_stdout=0x00885cf8 sv_stderr=0x00885d00 ...}  sub_process_t *
+       sv_stdin        0x00885cf0      int [2]
+       sv_stdout       0x00885cf8      int [2]
+       sv_stderr       0x00885d00      int [2]
        using_pipes     0x00000000      int
+       inp     0x00000000 <Bad Ptr>      char *
        incnt   0x00000000      unsigned long
+       outp    0x00000000 <Bad Ptr>      char * volatile
        outcnt  0x00000000      volatile unsigned long
+       errp    0x00000000 <Bad Ptr>      char * volatile
        errcnt  0x00000000      volatile unsigned long
        pid     0x00000bb4      int
        exit_code       0xc000013a      int
        signal  0x00000000      int
        last_err        0x00000000      long
        lerrno  0x00000000      long


>         make_msvc.net2003.exe!process_exit_code(void * proc=0x00885cf0)  Line 
> 185       C
        make_msvc.net2003.exe!reap_children()  Line 625 + 0xc   C
        make_msvc.net2003.exe!fatal_error_signal(int sig=0x00000002)  Line
466 + 0x9       C
        make_msvc.net2003.exe!ctrlevent_capture(unsigned long
CtrlType=0x00000000)  Line 129 + 0x7    C
        KERNEL32.DLL!7c5ade8e()         
        KERNEL32.DLL!7c5ade3e()         
        KERNEL32.DLL!7c57b388()         


So it looks as though the odd value is returned because main.c does not
handle signal?  Can you reproduce this situation Eli?

Kind regards
JG

#include <stdio.h>

int main()
{
        printf("counting:\n");
        size_t c = 0;
        size_t result = 0;
        for(; c != 2000000000; ++c)
        {
                //printf("%d\n", c);
                result ++;
        }

        c = 0;
        for(; c != 2000000000; ++c)
        {
                //printf("%d\n", c);
                result ++;
        }

        printf("%d\n", result);
        return 0;
}


all: temp1 temp2

temp1:
        ./main

temp2:
        ./main