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

[Martin Dorey]

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.com@gnu.org <bug-make-bounces+martin.dorey=hds.com@gnu.org> on behalf of Paul Smith <psmith@gnu.org>
Sent: Tuesday, March 7, 2023 16:09
To: Satish Balay <balay@mcs.anl.gov>
Cc: bug-make@gnu.org <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.