[bug #57022] Error 127 executing a script with no #!

[Martin Dorey]

URL:
  <https://savannah.gnu.org/bugs/?57022>

                 Summary: Error 127 executing a script with no #!
                 Project: make
            Submitted by: mdorey
            Submitted on: Tue 08 Oct 2019 05:29:37 PM PDT
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
       Component Version: SCM
        Operating System: POSIX-Based
           Fixed Release: None
           Triage Status: None

    _______________________________________________________

Details:

Here's a test case running against glibc 2.19 on 2015's Debian Jessie showing
that /usr/local/bin/make, which is 4.2.92, has regressed over /usr/bin/make,
which is 4.0 and (not shown) 4.2.1, in that executing a script with no #! line
fails with no diagnostic more informative than "Error 127":

martind@swiftboat:~/playpen/make-2019-10-08$ cat > Makefile
all: ; ./dodgy
martind@swiftboat:~/playpen/make-2019-10-08$ cat > dodgy
true
martind@swiftboat:~/playpen/make-2019-10-08$ chmod +x dodgy
martind@swiftboat:~/playpen/make-2019-10-08$ make
./dodgy
make: *** [Makefile:1: all] Error 127
martind@swiftboat:~/playpen/make-2019-10-08$ /usr/bin/make
./dodgy
martind@swiftboat:~/playpen/make-2019-10-08$ strace -f make 2>&1 | grep
execve
execve("/usr/local/bin/make", ["make"], [/* 209 vars */]) = 0
[pid 21223] execve("./dodgy", ["./dodgy"], [/* 212 vars */]) = -1 ENOEXEC
(Exec format error)
martind@swiftboat:~/playpen/make-2019-10-08$ strace -f /usr/bin/make 2>&1 |
grep execve
execve("/usr/bin/make", ["/usr/bin/make"], [/* 209 vars */]) = 0
[pid 21247] execve("./dodgy", ["./dodgy"], [/* 212 vars */]) = -1 ENOEXEC
(Exec format error)
[pid 21247] execve("/bin/sh", ["/bin/sh", "./dodgy"], [/* 212 vars */]) = 0
martind@swiftboat:~/playpen/make-2019-10-08$

ltrace -f showed I was using posix_spawn.

This:

make: *** [Makefile:1: all] Error 127

... is the same obtuse error message as Paul reported as applying not just to
old libc but also to Mac OS in a bug-make email thread regarding ENOENT rather
than ENOEXEC:

Handling posix_spawn for non-existent binaries

I foolishly reanimated the issue today on the still older thread:

ENOEXEC from exec*() functions...?

The Make source moved on since both of those threads under:

https://savannah.gnu.org/bugs/?56834
[SV 56834] Support local PATH search with posix_spawnp

... in that we now just use posix_spawn rather than posix_spawnp and Paul
added a call to findprog-in, which is perhaps why I can no longer reproduce
his ENOENT problem.  Paul also added ENOEXEC handling, but that doesn't work
when the failures are asynchronously notified, which I've now found was
addressed in glibc 2.24 under:

https://sourceware.org/bugzilla/show_bug.cgi?id=18433
posix_spawn does not return correctly upon failure to execute

That's the version shipped with 2017's Debian Stretch, currently "oldstable",
so you have to be quite out of date to see the problem on Linux.

So I did:

./configure --disable-posix-spawn
make -j8 MAKE_CFLAGS=

(
MAKE_CFLAGS= is Paul's recommendation in README.git to get round
-Wformat-signedness -Wduplicated-cond not being supported and:

src/job.c:2267:7: error: variable ‘fderr’ might be clobbered by
‘longjmp’ or ‘vfork’ [-Werror=clobbered]
)

... then I'm good.  I've contrived a patch for the configury which seemed to .
 It's my first non-trivial autotools code, so it's probably cargo cult
nonsense.  The test would better reveal the intention if it explicitly looked
for ENOEXEC, but that would be a little more code.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Tue 08 Oct 2019 05:29:37 PM PDT  Name:
automatically-disable-posix-spawn.patch  Size: 1KiB   By: mdorey

<http://savannah.gnu.org/bugs/download.php?file_id=47629>

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57022>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/