[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: J. Grant
Subject: Re: WINDOWS32 "Signal 127" due to a path in quotes bug
Date: Mon, 01 Aug 2005 00:09:54 +0100
User-agent: Mozilla/5.0 (X11; U; GNU/Linux i686; en; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1


>> 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
make: *** [temp1] Interrupt
make: *** [temp2] Interrupt

MSYS, with MSVC build:

make -f makefile_sig.mak -j8



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?


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

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
#include <stdio.h>

int main()
        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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]