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