Re: segfault on menu-select

[Bart Schaefer <schaefer@brasslantern.com>]

On Aug 13, 10:08am, Philipp Hartwig wrote:
}
} Note that in order to reproduce the issue it really seems to be 
} necessary to have the 4 lines
} 
} autoload -Uz compinit
} compinit
} zmodload -i zsh/complist
} bindkey '^o' menu-select
} 
} in your .zshrc. Just typing them or sourcing a file containing them will 
} not lead to the crash in my case, even without the "-f" option.

Hmm, indeed.  I'm finally able to reproduce this.  It's also necessary to
have invoked completion once before trying menu-select, just hitting ^o
won't do it (in fact, won't do *anything*, which is slightly suspicious).

The more direct symptom is that there's garbage in minfo.group->matches
("minfo" is a global).  I tried putting a watchpoint on minfo.group but
because matches is a pointer that's not very helpful; all I determined
is that it's last assigned here:

Hardware watchpoint 1: minfo.group

Old value = 0x8853ea8
New value = 0x8872690
0x08103002 in do_allmatches (end=0)
    at ../../../zsh-4.0/Src/Zle/compresult.c:902
902         for (minfo.group = amatches;

At which point the contents of ->matches look like this:

(gdb) p m
$6 = 0x8d1efa8
(gdb) p *m
$7 = {str = 0x0, orig = 0x21 <Address 0x21 out of bounds>, 
  ipre = 0x886fcf8 "", 
  ripre = 0x8b6870 "(·Ô\b@\031\205\b¨ïÑ\b\230\032\207\b
ÔÔ\b\210õ\206\b \211Ò\b eÏ\b mÔ\b0ûÑ\b8oÏ\b(nÏ\b°éÒ\bhÆÓ\b@`Ô\b@`Ô\b¨<\205\b¨<\205\b\b|\206\b¸Â\204\b¸h\213",
isuf = 0x5f73756f <Address 0x5f73756f out of bounds>, 
  ppre = 0x69736f70 <Address 0x69736f70 out of bounds>, 
  psuf = 0x6e6f6974 <Address 0x6e6f6974 out of bounds>, prpre = 0x8d10073 "", 
  pre = 0x20 <Address 0x20 out of bounds>, 
  suf = 0x10 <Address 0x10 out of bounds>, 
  disp = 0x6d75645f <Address 0x6d75645f out of bounds>, 
  autoq = 0x6d646170 <Address 0x6d646170 out of bounds>, flags = 0, 
  brpl = 0x19, brsl = 0x0, rems = 0x8d23720 "dmeventd", remf = 0x0, 
  qipl = 142976480, qisl = 0, rnum = 17, gnum = 7173740, mode = 9136216, 
  modec = 0 '\0', fmode = 25, fmodec = -112 '\220'}

However, the crash doesn't always happen that deep in the call stack;
having the hardware watchpoint present changes the behavior a bit, so I
suspect *amatches has already been messed up for a while at this point.

Unfortunately I'm out of time to poke at it just now.

--