This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about executable startup failure

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:
> 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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]