[zsh 5.0.2] Referencing $WIDGET can cause a segfault.

[tallus]

In zsh-syntax-highlighting/highlighters/main/main-highlighter.zsh on line 66 there's a reference to $WIDGET.
_zsh_highlight_main_highlighter_predicate()
{
[[ $WIDGET == accept-* ]] ||
_zsh_highlight_buffer_modified
}
Most of the time this is unproblematic. However if a TRAPWINCH function is defined that calls zle/zle reset-prompt (which is a typical use case for it) it will cause a segfault, though only if there has been no user interaction (typing anything will prevent it).

This is a fairly obscure issue and properly is an upstream bug* (which I've reported) but I'm also reporting it here as this is what originally triggered it. I came across it by having both zsh-syhntax-highlighting and vi-mode (which defines TRAPWINCH) enabled as plugins in on-my-zsh.

• it can be triggered by defining a TRAPWINCH like, say TRAPWINCH(){echo $WIDGET}, absent z-sy-h, or reset-prompt. Though it seems that zle reset-prompt is the bit that results in the call to _zsh_highlight_main_highlighter_predicate via line 92 in zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

[danielshahaf]

This is a fairly obscure issue and properly is an upstream bug* (which I've reported)but I'm also reporting it here as this is what originally triggered it.

Agreed and thanks. I'll see if there's anything z-sy-h can do to avoid triggering this upstream bug.

Could you please post exact reproduction instructions, starting from zsh -f + source zsh-syntax-highlighting.zsh? I haven't been able to reproduce this with various permutations of bindkey -v/-e, TRAPWINCH()s, zsh versions, etc..

[danielshahaf]

Upstream report: workers/38627

This happens in 5.0.2 but not in 5.0.7.

[tallus]

I'm on 5.0.2, this the version in Ubuntu 14.0.4 LTS. Hence why it shows up for me but not you.

I've attached a minimal .zshrc I was using to test this.
zshrc-reproduce.txt

I'm not sure when it was fixed but testing against $ZSH_VERSION < "5.0.7" or $ZSH_VERSION > "5.0.2" might suffice.

Do you want me to submit a pull request with either of these? (I have a local fix that just uses _zsh_highlight_buffer_modified which I believe use to be the case generally until recently)

[danielshahaf]

What would the fix be? You can test the shell's version with is-at-least (and this is probably better than forking of a subshell and checking if it segfaults or not, since that might leave core files, syslog warnings, and so on), but what would you do if the shell version is ≤5.0.2 or in the range 5.0.2<⋯≤5.0.7?

Is there a way to reliably detect whether we're in a TRAPWINCH handler? If the trap were installed as TRAPWINCH() {…} then $funcstack (a parameter provided by the zsh/parameter module) contains "TRAPWINCH" as an element, but that doesn't happen for trap … WINCH traps.

So, how about: if $funcstack exists, and the shell version is in the suspected range, and we're in a TRAPWINCH handler according to $funcstack, then skip recomputing the syntax highlighting (and perhaps warn)?

Can you test whether the following prints "TRAPWINCH" in 5.0.2:

% f() { print -r -- $funcstack }
% zle -N f
% TRAPWINCH() { zle && { zle f; zle -R } }
% <resize the window>

This would not be a complete test — it wouldn't cover the classic-form traps nor builds without zsh/parameter (if there are any such builds in the wild) — but nonetheless, it should be sound in the common case. However, it would break the theoretical use-case of modifying $BUFFER and updating syntax highlighting in a TRAPWINCH handler; if we wish to support the latter we'd want to devise some way to have a TRAPWINCH handler update syntax highlighting, i.e., to disable/bypass the check described in the third paragraph.

[danielshahaf]

Ping?

[llllvvuu]

^ Yes, this prints TRAPWINCH.

[danielshahaf]

So the following approach should be safe:

So, how about: if $funcstack exists, and the shell version is in the suspected range, and we're in a TRAPWINCH handler according to $funcstack, then skip recomputing the syntax highlighting (and perhaps warn)?

Patches welcome.

---

This would not be a complete test [...] However, it would break the theoretical use-case of modifying $BUFFER and updating syntax highlighting in a TRAPWINCH handler;

Given that this breakage is (1) theoretical, (2) would be restricted to pre-5.0.7, I'm not too worried about it.