Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'

[Satish Balay]

Sorry - was a bit lazy - posted the stack trace from an earlier iteration where 
the test makefile has some more stuff [assumed it wouldn't make a difference 
wrt stack trace.]

Satish

----

balay@ypro ~ % cat makefile 
CONFIGDIR = ${PWD}/testdir/config
ifeq ($(wildcard ${PWD}/testdir/readme),)
  CONFIGDIR = ${PWD}/testdir/share/config
endif
all:
        -@echo "CONFIGDIR: ${CONFIGDIR}"
balay@ypro ~ % ./make-4.4.1/make 
zsh: segmentation fault  ./make-4.4.1/make
balay@ypro ~ % sudo lldb ./make-4.4.1/make
Password:
(lldb) target create "./make-4.4.1/make"
Current executable set to '/Users/balay/make-4.4.1/make' (x86_64).
(lldb) run
Process 29044 launched: '/Users/balay/make-4.4.1/make' (x86_64)
make was compiled with optimization - stepping may behave oddly; variables may 
not be available.
Process 29044 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x0)
    frame #0: 0x000000010001e00e make`parse_file_seq(stringp=<unavailable>, 
size=16, stopmap=1, prefix=0x0000000000000000, flags=25) at read.c:3535:11 [opt]
   3532           }
   3533         else
   3534 #endif /* !NO_ARCHIVES */
-> 3535           NEWELT (concat (2, prefix, nlist[i]));
   3536 
   3537       if (globme)
   3538         globfree (&gl);
Target 0: (make) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
(code=1, address=0x0)
  * frame #0: 0x000000010001e00e make`parse_file_seq(stringp=<unavailable>, 
size=16, stopmap=1, prefix=0x0000000000000000, flags=25) at read.c:3535:11 [opt]
    frame #1: 0x000000010000b576 make`func_wildcard [inlined] 
string_glob(line="/testdir/readme") at function.c:365:11 [opt]
    frame #2: 0x000000010000b55f make`func_wildcard(o="", argv=<unavailable>, 
funcname=<unavailable>) at function.c:1534 [opt]
    frame #3: 0x0000000100009f1f make`handle_function(op=0x00007ffeefbfebb8, 
stringp=<unavailable>) at function.c:2693:9 [opt]
    frame #4: 0x0000000100005e1f 
make`variable_expand_string(line=<unavailable>, string=<unavailable>, 
length=<unavailable>) at expand.c:282:17 [opt]
    frame #5: 0x0000000100006481 make`variable_expand(line=<unavailable>) at 
expand.c:441:10 [opt] [artificial]
    frame #6: 0x000000010001f3d9 make`conditional_line(line=<unavailable>, 
len=<unavailable>, flocp=0x00007ffeefbfee98) at read.c:1724:12 [opt]
    frame #7: 0x000000010001b7a0 make`eval(ebuf=<unavailable>, set_default=1) 
at read.c:785:17 [opt]
    frame #8: 0x000000010001b0f1 make`eval_makefile(filename=<unavailable>, 
flags=<unavailable>) at read.c:436:3 [opt]
    frame #9: 0x000000010001adb5 
make`read_all_makefiles(makefiles=<unavailable>) at read.c:253:11 [opt]
    frame #10: 0x0000000100016298 make`main(argc=1, argv=0x00007ffeefbffbe0, 
envp=0x00007ffeffffffff) at main.c:2081:18 [opt]
    frame #11: 0x00007fff6836ccc9 libdyld.dylib`start + 1
(lldb) exit
Quitting LLDB will kill one or more processes. Do you really want to proceed: 
[Y/n] y
balay@ypro ~ % sw_vers
ProductName:    Mac OS X
ProductVersion: 10.15.7
BuildVersion:   19H2026
balay@ypro ~ % clang --version
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
balay@ypro ~ % 

On Tue, 7 Mar 2023, Martin Dorey wrote:

> What a great looking bug report.  Tiny reproducer, clear range of things 
> tried, clear crash with an effort to debug it.  But there's a problem.  The 
> stack trace includes:
> 
>     frame #7: 0x00000001000096b1 make`variable_expand_string(line="", 
> string="$(wildcard $(PETSCCONFIGDIR)/gmakegentest.py)", 
> length=18446744073709551615) at expand.c:282:17
> 
> ... which suggests that the makefile under test contained the string 
> $(wildcard $(PETSCCONFIGDIR)/gmakegentest.py).  GNU make generate test dot 
> python, that seems unlikely to be corrupt, as does an abbreviation for 
> "petsc" configuration directory, yet the example makefile we're given doesn't 
> include those strings.  Also, perhaps lldb doesn't support environment 
> variable interpolation like this:
> 
> (lldb) run PETSC_DIR=$HOME/petsc
> 
> ... because:
> 
> $(PETSCCONFIGDIR)/gmakegentest.py
> 
> ... seems to have been expanded to:
> 
> /petsc/config/gmakegentest.py
> 
> ... rather than something involving /Users/balay.  Of course, Make shouldn't 
> crash when given unintentional input.
> 
> An x86-64 simd strlen implementation somehow running on an arm64 platform?  
> That's jolly clever.  The comment at the start of:
> 
> https://git.savannah.gnu.org/cgit/make.git/tree/src/read.c#n3535
> 
> ... says that prefix can be null, as the debugger suggests that it is, and 
> num == 0 would mean it's dealing with prefix in:
> 
> https://git.savannah.gnu.org/cgit/make.git/tree/src/misc.c#n216
> 
> ... but xstrlen handles the null pointer:
> 
> https://git.savannah.gnu.org/cgit/make.git/tree/src/makeint.h#n575
> 
> I wouldn't expect strlen to do so but I can imagine it doing so, in some 
> implementations, so a bit of a disappointment that it doesn't seem likely to 
> be that simple.
> 
> The stack trace bears a certain resemblance to one submitted by John 
> Graham-Cumming, also from a Mac, in:
> 
> https://lists.gnu.org/archive/html/bug-make/2022-09/msg00124.html
> 
> Sadly that thread went nowhere.  If someone could reproduce it and look at 
> all the local variables to form some opinion on whether the debugger is being 
> truthful and working out whether it's dereferenced null or some other invalid 
> pointer and where that might have come from...
> 
> ________________________________
> From: bug-make-bounces+martin.dorey=hds.com@gnu.org 
> <bug-make-bounces+martin.dorey=hds.com@gnu.org> on behalf of Satish Balay via 
> Bug reports and discussion for GNU make <bug-make@gnu.org>
> Sent: Tuesday, March 7, 2023 06:56
> To: bug-make@gnu.org <bug-make@gnu.org>
> Subject: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
> 
> ***** EXTERNAL EMAIL *****
> 
> This is likely a bug with this old version of macos/xcode. (sending in this 
> email to report this issue)
> 
> This test works fine with:
> - default MacOS /usr/bin/make
> - brew make-4.4.1
> - gnumake-4.2.1 compiled with xcode clang (version below)
> - gnumake-4.4.1 compiled with brew gcc (tried version 11)
> - gnumake-4.4.1 on arm64-apple-darwin22.3.0 with "Apple clang version 14.0.0 
> (clang-1400.0.29.202)"
> 
> 
> Fails with gnumake-4.3+ on arm64-apple-darwin21.4.0 with Apple clang version 
> 13.1.6 (clang-1316.0.21.2.3)
> Fails with gnumake-4.3+ (with xcode clang version below):
> 
> Built with  "./configure && make"
> 
> Thanks,
> Satish
> ----
> 
> balay@jpro^~ $ cat makefile
> CONFIGDIR = ${PWD}/testdir/config
> ifeq ($(wildcard ${PWD}/testdir/readme),)
>   CONFIGDIR = ${PWD}/testdir/share/config
> endif
> all:
>         -@echo "CONFIGDIR: ${CONFIGDIR}"
> balay@jpro^~ $ /usr/bin/make
> CONFIGDIR: /Users/balay/testdir/share/config
> balay@jpro^~ $ ./make-4.4.1/make
> Segmentation fault: 11
> balay@jpro^~ $ sw_vers
> ProductName: Mac OS X
> ProductVersion:  10.15.7
> BuildVersion:    19H2026
> balay@jpro^~ $ clang --version
> Apple clang version 12.0.0 (clang-1200.0.32.29)
> Target: x86_64-apple-darwin19.6.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> balay@jpro^~ $
> 
> 
> bash-3.2# lldb ./make-4.4.1/make
> (lldb) target create "./make-4.4.1/make"
> Current executable set to '/Users/balay/make-4.4.1/make' (x86_64).
> (lldb) run PETSC_DIR=$HOME/petsc
> Process 84468 launched: '/Users/balay/make-4.4.1/make' (x86_64)
> Process 84468 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=EXC_I386_GPFLT)
>     frame #0: 0x00007fff68562e52 libsystem_platform.dylib`_platform_strlen + 
> 18
> libsystem_platform.dylib`_platform_strlen:
> ->  0x7fff68562e52 <+18>: pcmpeqb (%rdi), %xmm0
>     0x7fff68562e56 <+22>: pmovmskb %xmm0, %esi
>     0x7fff68562e5a <+26>: andq   $0xf, %rcx
>     0x7fff68562e5e <+30>: orq    $-0x1, %rax
> Target 0: (make) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS 
> (code=EXC_I386_GPFLT)
>   * frame #0: 0x00007fff68562e52 libsystem_platform.dylib`_platform_strlen + 
> 18
>     frame #1: 0x00000001000278fd make`concat(num=0) at misc.c:216:18
>     frame #2: 0x000000010002e212 
> make`parse_file_seq(stringp=0x00007ffeefbfdf88, size=16, stopmap=1, 
> prefix=0x0000000000000000, flags=25) at read.c:3535:11
>     frame #3: 0x0000000100013a09 
> make`string_glob(line="/petsc/config/gmakegentest.py") at function.c:365:11
>     frame #4: 0x0000000100011210 make`func_wildcard(o="", 
> argv=0x00007ffeefbfe060, funcname="wildcard") at function.c:1534:14
>     frame #5: 0x000000010000f540 make`expand_builtin_function(o="", argc=1, 
> argv=0x00007ffeefbfe060, entry_p=0x000000010004cf50) at function.c:2570:12
>     frame #6: 0x000000010000f160 make`handle_function(op=0x00007ffeefbfe238, 
> stringp=0x00007ffeefbfe248) at function.c:2693:9
>     frame #7: 0x00000001000096b1 make`variable_expand_string(line="", 
> string="$(wildcard $(PETSCCONFIGDIR)/gmakegentest.py)", 
> length=18446744073709551615) at expand.c:282:17
>     frame #8: 0x0000000100009f83 make`variable_expand(line="$(wildcard 
> $(PETSCCONFIGDIR)/gmakegentest.py)") at expand.c:441:10
>     frame #9: 0x00000001000309af make`conditional_line(line=")", len=4, 
> flocp=0x00007ffeefbfe888) at read.c:1724:12
>     frame #10: 0x000000010002b0f7 make`eval(ebuf=0x00007ffeefbfe860, 
> set_default=1) at read.c:785:17
>     frame #11: 0x000000010002a85b make`eval_makefile(filename="makefile", 
> flags=0) at read.c:436:3
>     frame #12: 0x000000010002a233 
> make`read_all_makefiles(makefiles=0x0000000000000000) at read.c:253:11
>     frame #13: 0x0000000100021f90 make`main(argc=2, argv=0x00007ffeefbffba0, 
> envp=0x00007ffeefbffbb8) at main.c:2081:18
>     frame #14: 0x00007fff6836ccc9 libdyld.dylib`start + 1
> (lldb)
> 
>