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

[Satish Balay]

[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: 0x000000010002e202 
make`parse_file_seq(stringp=0x00007ffeefbfdfe8, size=16, stopmap=1, 
prefix=0x0000000000000000, 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 = 0x0000000000000000
(lldb) p nlist
(const char **) $1 = 0x7b7d41d100000000
(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: 0x000000010001e00e
> > make`parse_file_seq(stringp=<unavailable>, size=16, stopmap=1,
> > prefix=0x0000000000000000, 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
>