Segmentation fault with make-4.3+ on MacOS with 'wildcard'
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: 0x7fff68562e52 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: 0x7fff68562e52 libsystem_platform.dylib`_platform_strlen + 18
frame #1: 0x0001000278fd make`concat(num=0) at misc.c:216:18
frame #2: 0x00010002e212
make`parse_file_seq(stringp=0x7ffeefbfdf88, size=16, stopmap=1,
prefix=0x, flags=25) at read.c:3535:11
frame #3: 0x000100013a09
make`string_glob(line="/petsc/config/gmakegentest.py") at function.c:365:11
frame #4: 0x000100011210 make`func_wildcard(o="",
argv=0x7ffeefbfe060, funcname="wildcard") at function.c:1534:14
frame #5: 0x0001f540 make`expand_builtin_function(o="", argc=1,
argv=0x7ffeefbfe060, entry_p=0x00010004cf50) at function.c:2570:12
frame #6: 0x0001f160 make`handle_function(op=0x7ffeefbfe238,
stringp=0x7ffeefbfe248) at function.c:2693:9
frame #7: 0x000196b1 make`variable_expand_string(line="",
string="$(wildcard $(PETSCCONFIGDIR)/gmakegentest.py)",
length=18446744073709551615) at expand.c:282:17
frame #8: 0x00019f83 make`variable_expand(line="$(wildcard
$(PETSCCONFIGDIR)/gmakegentest.py)") at expand.c:441:10
frame #9: 0x0001000309af make`conditional_line(line=")", len=4,
flocp=0x7ffeefbfe888) at read.c:1724:12
frame #10: 0x00010002b0f7 make`eval(ebuf=0x7ffeefbfe860,
set_default=1) at read.c:785:17
frame #11: 0x00010002a85b make`eval_makefile(filename="makefile",
flags=0) at read.c:436:3
frame #12: 0x00010002a233
make`read_all_makefiles(makefiles=0x) at read.c:253:11
frame #13: 0x000100021f90 make`main(argc=2, argv=0x7ffeefbffba0,
envp=0x7ffeefbffbb8) at main.c:2081:18
frame #14: 0x7fff6836ccc9 libdyld.dylib`start + 1
(lldb)
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
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: 0x000196b1 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@gnu.org
on behalf of Satish Balay via
Bug reports and discussion for GNU make
Sent: Tuesday, March 7, 2023 06:56
To: 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: 0x7fff68562e52 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: 0x7fff68562e52 libsystem_platform.dylib`_platform_strlen + 18
frame #1: 0x0001000278fd make`concat(num=0) at misc.c:216:18
frame #2: 0x00010002e212
make`parse_file_seq(stringp=0x7ffeefbfdf88, size=16, stopmap=1,
prefix=0x, flags=25) at read.c:3535:11
frame #3: 0x000100013a09
make`string_glob(line="/petsc/config/gmakegentest.py") at function.c:365:11
frame #4: 0x000100011210 make`func_wildcard(o="",
argv=0x7f
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
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: 0x00010001e00e make`parse_file_seq(stringp=,
size=16, stopmap=1, prefix=0x, 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: 0x00010001e00e make`parse_file_seq(stringp=,
size=16, stopmap=1, prefix=0x, flags=25) at read.c:3535:11 [opt]
frame #1: 0x0001b576 make`func_wildcard [inlined]
string_glob(line="/testdir/readme") at function.c:365:11 [opt]
frame #2: 0x0001b55f make`func_wildcard(o="", argv=,
funcname=) at function.c:1534 [opt]
frame #3: 0x00019f1f make`handle_function(op=0x7ffeefbfebb8,
stringp=) at function.c:2693:9 [opt]
frame #4: 0x00015e1f
make`variable_expand_string(line=, string=,
length=) at expand.c:282:17 [opt]
frame #5: 0x00016481 make`variable_expand(line=) at
expand.c:441:10 [opt] [artificial]
frame #6: 0x00010001f3d9 make`conditional_line(line=,
len=, flocp=0x7ffeefbfee98) at read.c:1724:12 [opt]
frame #7: 0x00010001b7a0 make`eval(ebuf=, set_default=1)
at read.c:785:17 [opt]
frame #8: 0x00010001b0f1 make`eval_makefile(filename=,
flags=) at read.c:436:3 [opt]
frame #9: 0x00010001adb5
make`read_all_makefiles(makefiles=) at read.c:253:11 [opt]
frame #10: 0x000100016298 make`main(argc=1, argv=0x7ffeefbffbe0,
envp=0x7ffe) at main.c:2081:18 [opt]
frame #11: 0x7fff6836ccc9 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: 0x000196b1 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
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
On Tue, 2023-03-07 at 17:38 -0600, Satish Balay via Bug reports and discussion for GNU make wrote: > -> 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: 0x00010001e00e > make`parse_file_seq(stringp=, size=16, stopmap=1, > prefix=0x, flags=25) at read.c:3535:11 [opt] Can you show the value of the "prefix", "nlist", "i", and "nlist[i]" variables when this crash happens? (gdb) p prefix (gdb) p nlist (gdb) p i (gdb) p nlist[i] It seems there's a null pointer but I would like to know which pointer is null. I'm wondering if the crash is not in concat() at all, but rather in the NEWELT macro
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
[rebuilt make with CFLAGS=-g] Here is the gdb log Satish balay@ypro ~ % sudo 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) r Process 54199 launched: '/Users/balay/make-4.4.1/make' (x86_64) Process 54199 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) frame #0: 0x00010002e202 make`parse_file_seq(stringp=0x7ffeefbfdfe8, size=16, stopmap=1, prefix=0x, flags=25) at read.c:3535:11 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) p prefix (const char *) $0 = 0x (lldb) p nlist (const char **) $1 = 0x7b7d41d1 (lldb) p i (int) $2 = 0 (lldb) p nlist[i] error: Couldn't apply expression side effects : Couldn't dematerialize a result variable: couldn't read its memory (lldb) On Tue, 7 Mar 2023, Paul Smith wrote: > On Tue, 2023-03-07 at 17:38 -0600, Satish Balay via Bug reports and > discussion for GNU make wrote: > > -> 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: 0x00010001e00e > > make`parse_file_seq(stringp=, size=16, stopmap=1, > > prefix=0x, flags=25) at read.c:3535:11 [opt] > > Can you show the value of the "prefix", "nlist", "i", and "nlist[i]" > variables when this crash happens? > > (gdb) p prefix > (gdb) p nlist > (gdb) p i > (gdb) p nlist[i] > > It seems there's a null pointer but I would like to know which pointer > is null. > > I'm wondering if the crash is not in concat() at all, but rather in the > NEWELT macro >
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
On Tue, 2023-03-07 at 17:54 -0600, Satish Balay wrote: > (lldb) p nlist[i] > error: Couldn't apply expression side effects : Couldn't > dematerialize a result variable: couldn't read its memory Boy I really really dislike lldb as a tool. Does it work to install gdb with brew instead? Not sure if it's better at debugging the Apple clang output however. What about "p *nlist" since "i" is 0? Also, what happens if you run "p _ns" and "p __n"? Also, please report "p new" and "p newp". I actually happen to have access to a Macbook M1 system so I can try to reproduce this myself too. Thanks.
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
Is it possible that suspiciously half null pointer came from: https://git.savannah.gnu.org/cgit/make.git/tree/src/read.c#n3480 nlist = (const char **)gl.gl_pathv; ... and it's sliced off half the gl_pathv pointer through calling an implementation of glob that wasn't compatible with the declaration of the structure that Make is using? We have clear evidence of pointers being 64 bit, so surely sizeof(size_t) was 8 and the pointer we're after is just one size_t in: https://git.savannah.gnu.org/cgit/make.git/tree/gl/lib/glob.in.h#n75 ... so that seems a bit odd. I wonder if: p gl ... would give us an extra insight. Displaying all the locals in parse_file_seq might save back and forth: info locals ... would be the gdb syntax. From: bug-make-bounces+martin.dorey=hds@gnu.org on behalf of Paul Smith Sent: Tuesday, March 7, 2023 16:09 To: Satish Balay Cc: bug-make@gnu.org Subject: Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard' * EXTERNAL EMAIL * On Tue, 2023-03-07 at 17:54 -0600, Satish Balay wrote: > (lldb) p nlist[i] > error: Couldn't apply expression side effects : Couldn't > dematerialize a result variable: couldn't read its memory Boy I really really dislike lldb as a tool. Does it work to install gdb with brew instead? Not sure if it's better at debugging the Apple clang output however. What about "p *nlist" since "i" is 0? Also, what happens if you run "p _ns" and "p __n"? Also, please report "p new" and "p newp". I actually happen to have access to a Macbook M1 system so I can try to reproduce this myself too. Thanks.
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
On Wed, 2023-03-08 at 00:13 +, Martin Dorey wrote: > ... and it's sliced off half the gl_pathv pointer through calling an > implementation of glob that wasn't compatible with the declaration of > the structure that Make is using? Well, since this is a MacOS system we SHOULD be using our own implementation of glob, not the system glob. Of course it could well be that some aspect of that implementation doesn't play well with MacOS arm64. It is quite old. I agree it seems extremely strange that nlist is not expandable, but let's see if *nlist works instead of nlist[0]. FYI I tested on a system I have access to: $ sw_vers ProductName:macOS ProductVersion: 11.7.2 BuildVersion: 20G1020 $ clang --version Apple clang version 12.0.5 (clang-1205.0.22.9) Target: arm64-apple-darwin20.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin but it worked fine with the makefile provided (of course I don't know what the directory structure is where you're running this so I couldn't reproduce that.
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
On Tue, 7 Mar 2023, Paul Smith wrote:
> On Wed, 2023-03-08 at 00:13 +, Martin Dorey wrote:
> > ... and it's sliced off half the gl_pathv pointer through calling an
> > implementation of glob that wasn't compatible with the declaration of
> > the structure that Make is using?
>
> Well, since this is a MacOS system we SHOULD be using our own
> implementation of glob, not the system glob. Of course it could well
> be that some aspect of that implementation doesn't play well with MacOS
> arm64. It is quite old.
>
> I agree it seems extremely strange that nlist is not expandable, but
> let's see if *nlist works instead of nlist[0].
>
> FYI I tested on a system I have access to:
>
> $ sw_vers
> ProductName:macOS
> ProductVersion: 11.7.2
> BuildVersion: 20G1020
>
> $ clang --version
> Apple clang version 12.0.5 (clang-1205.0.22.9)
> Target: arm64-apple-darwin20.6.0
> Thread model: posix
> InstalledDir: /Library/Developer/CommandLineTools/usr/bin
>
> but it worked fine with the makefile provided (of course I don't know
> what the directory structure is where you're running this so I couldn't
> reproduce that.
CONFIGDIR = ${PWD}/testdir/config
balay@ypro ~ % ls ${PWD}/testdir
ls: /Users/balay/testdir: No such file or directory
The failure occurs even if I create this file
balay@ypro ~ % mkdir testdir
balay@ypro ~ % touch testdir/config
balay@ypro ~ % ls -l ls ${PWD}/testdir/config
ls: ls: No such file or directory
-rw-r--r-- 1 balay staff 0 Mar 7 19:16 /Users/balay/testdir/config
balay@ypro ~ % ./make-4.4.1/make
zsh: segmentation fault ./make-4.4.1/make
balay@ypro ~ %
Its strange that it works on some systems [yours and another one mentioned
earlier :arm64-apple-darwin22.3.0 with "Apple clang version 14.0.0
(clang-1400.0.29.202)"] but not on the systems I have access to. [also listed
earlier..]
Satish
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
Ok - here it is.
Satish
(lldb) p *nlist
error: Couldn't apply expression side effects : Couldn't dematerialize a result
variable: couldn't read its memory
(lldb) v
(char **) stringp = 0x7ffeefbfdfe8
(size_t) size = 16
(int) stopmap = 1
(const char *) prefix = 0x
(int) flags = 25
(int) cachep = 0
(nameseq *) new = 0x
(nameseq **) newp = 0x7ffeefbfdf80
(char *) p = 0x00010080e81f ""
(glob_t) gl = {
gl_pathc = 1
gl_pathv = 0x7b7ddbde
gl_offs = 0
gl_flags = 512
gl_closedir = 0x00010080e790 (0x00010080e790)
gl_readdir = 0x
gl_opendir = 0x000189b0 (make`open_dirstream at dir.c:1217)
gl_lstat = 0x7fff684b4714 (libsystem_kernel.dylib`lstat$INODE64)
gl_stat = 0x7fff684af31c (libsystem_kernel.dylib`stat$INODE64)
}
(char *) tp = 0x00010080a200 "/testdir/readme"
(int) findmap = 3
(int) found_wait = 0
(const char *) name = 0x00010080a200 "/testdir/readme"
(const char **) nlist = 0x7b7ddbde
(char *) tildep = 0x
(int) globme = 1
(char *) arname = 0x
(char *) memname = 0x
(char *) s = 0x00010080e810 "/testdir/readme"
(size_t) nlen = 15
(int) tot = 1
(int) i = 0
(nameseq *) _ns = 0x00010080e7b0
(const char *) __n = 0x
(lldb)
On Wed, 8 Mar 2023, Martin Dorey wrote:
> Is it possible that suspiciously half null pointer came from:
>
> https://git.savannah.gnu.org/cgit/make.git/tree/src/read.c#n3480
>
>
> nlist = (const char **)gl.gl_pathv;
>
> ... and it's sliced off half the gl_pathv pointer through calling an
> implementation of glob that wasn't compatible with the declaration of the
> structure that Make is using? We have clear evidence of pointers being 64
> bit, so surely sizeof(size_t) was 8 and the pointer we're after is just one
> size_t in:
>
> https://git.savannah.gnu.org/cgit/make.git/tree/gl/lib/glob.in.h#n75
>
> ... so that seems a bit odd. I wonder if:
>
> p gl
>
> ... would give us an extra insight. Displaying all the locals in
> parse_file_seq might save back and forth:
>
> info locals
>
> ... would be the gdb syntax.
>
> From: bug-make-bounces+martin.dorey=hds@gnu.org
> on behalf of Paul Smith
>
> Sent: Tuesday, March 7, 2023 16:09
> To: Satish Balay
> Cc: bug-make@gnu.org
> Subject: Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
>
> * EXTERNAL EMAIL *
>
> On Tue, 2023-03-07 at 17:54 -0600, Satish Balay wrote:
> > (lldb) p nlist[i]
> > error: Couldn't apply expression side effects : Couldn't
> > dematerialize a result variable: couldn't read its memory
>
> Boy I really really dislike lldb as a tool. Does it work to install
> gdb with brew instead? Not sure if it's better at debugging the Apple
> clang output however.
>
> What about "p *nlist" since "i" is 0?
>
> Also, what happens if you run "p _ns" and "p __n"?
>
> Also, please report "p new" and "p newp".
>
> I actually happen to have access to a Macbook M1 system so I can try to
> reproduce this myself too.
>
> Thanks.
>
>
Re: Segmentation fault with make-4.3+ on MacOS with 'wildcard'
On Tue, 7 Mar 2023, Satish Balay wrote: > On Tue, 7 Mar 2023, Satish Balay wrote: > > > On Tue, 7 Mar 2023, Paul Smith wrote: > > > > > FYI I tested on a system I have access to: > > > > but it worked fine with the makefile provided (of course I don't know > > > what the directory structure is where you're running this so I couldn't > > > reproduce that. > > > Its strange that it works on some systems [yours and another one mentioned > > earlier :arm64-apple-darwin22.3.0 with "Apple clang version 14.0.0 > > (clang-1400.0.29.202)"] but not on the systems I have access to. [also > > listed earlier..] > > Attaching build logs [perhaps there are differences here that result in > different behavior] > > balay@ypro make-4.4.1 % ./configure >& configure-out.log && make -j8 > CFLAGS=-g >& make.log gcc -D_THREAD_SAFE -I/usr/local/Cellar/guile/3.0.7_2/include/guile/3.0 -I/usr/local/opt/gmp -I/usr/local/opt/gmp/include -I/usr/local/opt/readline/include -I/usr/local/opt/bdw-gc/include -g -rdynamic -o make src/ar.o src/arscan.o src/commands.o src/default.o src/dir.o src/expand.o src/file.o src/function.o src/getopt.o src/getopt1.o src/guile.o src/hash.o src/implicit.o src/job.o src/load.o src/loadapi.o src/main.o src/misc.o src/output.o src/read.o src/remake.o src/rule.o src/shuffle.o src/signame.o src/strcache.o src/variable.o src/version.o src/vpath.o src/posixos.o src/remote-stub.o -L/usr/local/Cellar/guile/3.0.7_2/lib -L/usr/local/opt/bdw-gc/lib -lguile-3.0 -lgc -lpthread lib/libgnu.a -L/usr/local/lib -lintl -Wl,-framework -Wl,CoreFoundation Ok - try a build without guile: balay@ypro make-4.4.1 % ./configure --without-guile && make -j8 Now it works! : balay@ypro ~ % ./make-4.4.1/make CONFIGDIR: /Users/balay/testdir/share/config balay@ypro ~ % So there must be some bad interaction with picking up brew installed guile libs here... Satish
