Re: Question about executable startup failure

Re: Question about executable startup failure

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

> > During startup program exited with code 0xc0000139.

> so Windows handles termination.

IMO if it did, the exit code wouldn't have been 127 but something with decimal equivalent of 0x139 (or the likes).

> P.S. I didn't get to know what exactly the entry point was missing that the 
> binary required (obviously from the newer Cygwin ABI).

Running under strace gets a Windows error popup "thebadexecutable.exe - Entry Point Not Found", that says inside:

---
The procedure entry point uname_x could not be located in the dynamic link library
C:\Cygwin64\home\user\thebadexecutable.exe
---

where thebadexecutable.exe in the above, is the executable being attempted to run.

In case of running it from the shell, nothing like that appears.

--
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: Question about executable startup failure

[Brian Inglis]

On 2019-11-13 23:48, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin wrote:
> Here's a situation: I have a binary that was built (from a C source code)
> with Cygwin 3.0.7 but "accidentally" used with much older Cygwin 2.11.2.
> 
> The binary won't actually launch.  Instead, it most uneventfully (silently, 
> no crash - no drama) exits with an exit code of 127, meaning "command not 
> found". The same exit code would have resulted from any mistyped command,
> which shell couldn't recognize / locate a matching file for (yet it won't be
> shy of saying so).
> 
> When I start the binary under debugger, I see the following:
> 
> [New Thread 12576.0x4d70]
> [New Thread 12576.0x4860]
> [New Thread 12576.0x44b8]
> [New Thread 12576.0x4528]
> [Thread 12576.0x44b8 exited with code 3221225785]
> [Thread 12576.0x4860 exited with code 3221225785]
> During startup program exited with code 0xc0000139.
> 
> So there's actually an explanation:  0xc0000139(=3221225785) is defined to be
> 
> ntstatus.h:#define STATUS_ENTRYPOINT_NOT_FOUND ((NTSTATUS)0xC0000139)
> 
> Now, the question is:  is it by design that the exit code is posted so 
> timidly?  Shouldn't there be a message that some dynamic linkage wasn't
> satisfied?
> Wouldn't 126 (which is "command cannot execute") be a better choice for the 
> exit code in this case?  Especially if the message cannot be produced at
> all?
> 
> I mean, it is actually a good thing that the executable won't start if it 
> happens to be incompatible with some random Cygwin version;  it just needs to
> be more vocal about the problem and post a more appropriate exit code, too.
> 
> Thanks,
> Anton
> 
> P.S. I didn't get to know what exactly the entry point was missing that the 
> binary required (obviously from the newer Cygwin ABI).
> 
> Reference:
> https://pubs.opengroup.org/onlinepubs/9699919799//utilities/V3_chap02.html#tag_18_08_02
> If a command is not found, the exit status shall be 127. If the command name
> is found, but it is not an executable utility, the exit status shall be
> 126. Applications that invoke utilities without using the shell should use
> these exit status values to report similar errors.

That assumes a POSIX layer is in control: with incompatible Cygwin ABI versions,
calling a missing entrypoint, Cygwin did not get far enough through startup to
detect and report the mismatch; gdb says so here:

> During startup program exited with code 0xc0000139.

so Windows handles termination.

$ fgrep -R 'During startup program exited with code' src/cygwin/newlib-cygwin/
$ fgrep -R 'During startup program exited with code' /bin/
Binary file /bin/gdb.exe matches

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

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

Question about executable startup failure

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via cygwin]

Hi all,

Here's a situation: I have a binary that was built (from a C source code) with Cygwin 3.0.7 but "accidentally" used with much older Cygwin 2.11.2.

The binary won't actually launch.  Instead, it most uneventfully (silently, no crash - no drama) exits with an exit code of 127, meaning "command not found".  The same exit code would have resulted from any mistyped command, which shell couldn't recognize / locate a matching file for (yet it won't be shy of saying so).

When I start the binary under debugger, I see the following:

[New Thread 12576.0x4d70]
[New Thread 12576.0x4860]
[New Thread 12576.0x44b8]
[New Thread 12576.0x4528]
[Thread 12576.0x44b8 exited with code 3221225785]
[Thread 12576.0x4860 exited with code 3221225785]
During startup program exited with code 0xc0000139.

So there's actually an explanation:  0xc0000139(=3221225785) is defined to be

ntstatus.h:#define STATUS_ENTRYPOINT_NOT_FOUND ((NTSTATUS)0xC0000139)

Now, the question is:  is it by design that the exit code is posted so timidly?  Shouldn't there be a message that some dynamic linkage wasn't satisfied?
Wouldn't 126 (which is "command cannot execute") be a better choice for the exit code in this case?  Especially if the message cannot be produced at all?

I mean, it is actually a good thing that the executable won't start if it happens to be incompatible with some random Cygwin version;  it just needs to be more vocal about the problem and post a more appropriate exit code, too.

Thanks,
Anton

P.S. I didn't get to know what exactly the entry point was missing that the binary required (obviously from the newer Cygwin ABI).

Reference:
https://pubs.opengroup.org/onlinepubs/9699919799//utilities/V3_chap02.html#tag_18_08_02
If a command is not found, the exit status shall be 127. If the command name is found, but it is not an executable utility, the exit status shall be 126. Applications that invoke utilities without using the shell should use these exit status values to report similar errors.

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