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