sh.exe returns incorrect exit code

[Tom Honermann]

On 01/31/2014 03:11 PM, Darrel Laursen wrote:

Hey Darrel!  Nice to see you popping up here!

> Below is the relevant process tree.
>
> make.exe (PID=77256) launches sh.exe -c "pscl.exe . || (shopt -s nullglob && rm -f xxx.obj; exit 1)"
> +--- sh.exe (PID=94584) launches sh.exe <no command line given>
>       +--- sh.exe (PID=32240) launches pscl.exe .
>            +--- pscl.exe (PID=135060-a Win32 executable) launches a bunch of subprocesses .
>            +--- pscl.exe (PID=135060) exits with errorlevel 0
>       +--- sh.exe (PID=32240) exits with errorlevel 32256 (0x7E00)
> +--- sh.exe (PID=94584) launches sh.exe <no command line given>
>       +--- sh.exe (PID=84604) launches sh.exe <no command line given>
>            +--- sh.exe (PID=156240) launches rm.exe -f xxx.obj
>                 +--- rm.exe (PID=884) runs
>            +--- sh.exe (PID=156240) exits with errorlevel 0
>                 +--- rm.exe (PID=884) exits with errorlevel 1
>       +--- sh.exe (PID=84604) exits with errorlevel 256
> +--- sh.exe (PID=94584) exits with errorlevel 1
> make.exe exits with errorlevel 2
>
> The errorlevel 32256 (0x7E00) returned by PID 32240 (the forked copy
> of sh.exe) is bogus. Any idea what errorlevel 32256 means between
> sh.exe and its forked copy of itself? I don't really know how to
> check this further. I'm hoping someone can help me determine what
> this return code represents and why the forked copy of sh.exe would
> return it.
>
> I can see how fork() starts a second copy of the same cygwin
> executable (for sh.exe at least). There appears to be some special
> return code numbering system between sh.exe and the forked child copy
> of itself. Later another forked copy of sh.exe (PID=84604) exits with
> code 256 and the parent copy of sh.exe (PID=94584) translates this to
> its own exit code of 1 which is the correct final value for that
> situation. In other parts of the process tree not shown here I can
> see the forked sh.exe exits with 512 and the parent sh.exe correctly
> translate this to its own exit code 2. If the cygwin/sh.exe protocol
> is for the parent to take the forked copy's exit code and right shift
> it 8 bits, then this means a forked exit code of 0x7E00 translates to
> a real exit code of 0x7E (0n126). Does exit code 126 correspond with
> some internal sh.execoncept?

sh exit code 126 is documented by POSIX [1] to indicate that a command 
specified a (non-builtin) utility to run, that a file matching the name 
was found, but that the file was not executable.

The process tree above doesn't appear to match that exit code 
description however.

I would suspect [2], but if I remember correctly, pscl.exe is not 
multi-threaded.

I presume the process tree above was captured from your native build. 
Have you been able to reproduce the issue in a smaller test case?  For 
example, I'm running the following right now to see if I can provoke a 
similar failure (note that this invokes Microsoft's cl.exe (from VS 
2010) instead of pscl.exe).  I'm also running GNU bash 4.1.10(4)-release 
(on Cygwin 1.7.23-1).  Perhaps you can try this with pscl.exe?

$ cat doit.sh
#!/bin/sh

while [ 1 ]; do
   make || {
     echo "make failed unexpectedly"
     break
   }
done

$ cat Makefile
all:
         cl.exe /c t.cpp || (shopt -s nullglob && rm -f t.obj; exit 1)

$ cat t.cpp
int i;

Tom.

[1]: 
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02
[2]: http://support.microsoft.com/kb/2875501

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