Okay, the good news first: I found the culprit! The issue was caused by
the zsh-syntax-highlighting script
(https://github.com/zsh-users/zsh-syntax-highlighting). If I stop
sourcing that script everything works beautifully. The problems seems to
stem from the fact that that script rebinds all of the widgets to invoke
the highlighting routine after them:
https://github.com/zsh-users/zsh-syntax-highlighting/blob/master/zsh-syntax-highlighting.zsh#L127
Unfortunately I don't know enough about the widget stuff to pinpoint the
exact reason this makes it fail. I've sourced that script after the zle
changes so far, but a quick swapping of order doesn't seem to make any
difference.

During my tests I also found a way to make zsh segfault. While I still
had the above script enabled I occasionally encountered some strange
behaviour, described in this sequence:

  1. Press ^r and enter something common like 'ls', the first result
     gets displayed
  2. Press ^r again, a "failing bck-i-search" message gets displayed
  3. Press ^r again, another result from the history gets displayed (huh?)
  4. Press ^r again, "failing" message again and/or segfault

In the cases where it doesn't segfault in step 4 pressing ^r more often
after that just results in more "failing" messages. I've attached a full
backtrace of the segfault case. This is with release 5.0.5 on Debian, by
the way.

On 03/03/14 18:44, Bart Schaefer wrote:
> HOWEVER, I think this may be the source of the bug.  Repeating the
> search does not exit from the isearch keymap, so zle-isearch-exit is
> always called between any two calls of the custom widget.  Thus the
> [[ $LASTWIDGET != history-incremental-pattern-search-backward ]]  test
> is probably incorrect part of the time.
>
> Try changing to
>
>     history-incremental-pattern-search-backward() {
> 	NUMERIC=0 zle set-local-history
> 	zle .history-incremental-pattern-search-backward "$@"
>     }
>
> and see if that clears it up?

This didn't change anything with the highlighting script still enabled,
and I didn't see any immediate difference when doing some quick tests
after disabling that script, but I'll try to investigate further.

Thanks for the help!

-Jan