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 = 0x00007ffeefbfdfe8
(size_t) size = 16
(int) stopmap = 1
(const char *) prefix = 0x0000000000000000
(int) flags = 25
(int) cachep = 0
(nameseq *) new = 0x0000000000000000
(nameseq **) newp = 0x00007ffeefbfdf80
(char *) p = 0x000000010080e81f ""
(glob_t) gl = {
gl_pathc = 1
gl_pathv = 0x7b7ddbde00000000
gl_offs = 0
gl_flags = 512
gl_closedir = 0x000000010080e790 (0x000000010080e790)
gl_readdir = 0x0000000000000000
gl_opendir = 0x00000001000089b0 (make`open_dirstream at dir.c:1217)
gl_lstat = 0x00007fff684b4714 (libsystem_kernel.dylib`lstat$INODE64)
gl_stat = 0x00007fff684af31c (libsystem_kernel.dylib`stat$INODE64)
}
(char *) tp = 0x000000010080a200 "/testdir/readme"
(int) findmap = 3
(int) found_wait = 0
(const char *) name = 0x000000010080a200 "/testdir/readme"
(const char **) nlist = 0x7b7ddbde00000000
(char *) tildep = 0x0000000000000000
(int) globme = 1
(char *) arname = 0x0000000000000000
(char *) memname = 0x0000000000000000
(char *) s = 0x000000010080e810 "/testdir/readme"
(size_t) nlen = 15
(int) tot = 1
(int) i = 0
(nameseq *) _ns = 0x000000010080e7b0
(const char *) __n = 0x0000000000000000
(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
> <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.
>
>
