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

[Satish Balay]

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.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.
> 
>