Re: [BUG] Ctrl-C stops working after process substitution

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 5 July 2018 at 10:44, Peter Stephenson <p.stephenson@xxxxxxxxxxx> wrote:
At the end there's a check for errflag and if
> it's set the error bit ERRFLAG_ERROR is removed and we ignore that
> FD until the read function returns.  There could be something
> unhelpful in this area.  In particular we don't do anything with
> the interrupt bit ERRFLAG_INT or a hard error ERRFLAG_HARD.
>
> But that's just a guess.

I have an observation. I configure LLDB to pass SIGINT to program.
LLDB shows this table:

NAME         PASS   STOP   NOTIFY
===========  =====  =====  ======
SIGINT       true   true   true

So on Ctrl-C, it will be passed to program and program will be stopped
(i.e. debugger will stop program to allow stepping, etc.).

I then attach to proper PID of a Zsh instance. Then press Ctrl-C –
debugger activates, Zsh obtains signal. Ok.

Then I paste some text into Zsh so that Fast Syntax Highlighting runs
zle -F -w handlers that check if string is a path (to highlight this
string).

So far so good. Then I press Ctrl-C and (IMPORTANT) – nothing happens.
Even debugger doesn't activate. I can press Ctrl-C many times. Pasting
text that runs zle -F -w stuff leaves Zsh and debugger blind to
Ctrl-C. Isn't this a masking of interrupt? This would explain the main
problem – no reaction to Ctrl-C.

If I then use the known method to dig-out from this improper state –
Ctrl-D, then Ctrl-C starts working again – debugger notices it and
activates, program obtains it (zhandler is called).

So what could mask SIGINT as the result of pasting text and zle -F -w
invocation? There's a hint: pasting the text into command line causes
zhandler invocations (I have breakpoint in zhandler). I paste string
"NAME" (header of the table) – nothing happens. Press space, then
paste "NAME" again – now Fast Syntax Highlighting will run zle -F -w
because "NAME" occurs as program argument, and can potentially be a
path. Effect: two zhandler calls:

    frame #0: 0x000000010f8517d2 zsh`zhandler(sig=20) at signals.c:601
-> 601         last_signal = sig;
   602         signal_process(sig);

sig == 20, then some stuff is executed that isn't clear for me yet.

What can be happening? SIGINT (?) reaching zhandler two times, just
because I pasted text that ran zle -F -w?

I then go final minimal thing: start zsh -f and run:

noop() { print "I'm ran" >> /tmp/reply; IFS='' read line; MYFD="$1";
zle -F "$1"; exec {MYFD}<&-; };
exec {MYFD}< <( echo a test ); attach() { zle -F -w $MYFD noop; }; zle
-N noop; attach

And – zhandler is called! It's pure-empty, clear Zshell, no
fast-syntax-highlighting, so just pasting doesn't yield any debugger
reaction. But running it calls zhandler (sig==20) two times. I then
minimize further:

exec {MYFD}< <( echo a test )

This code starts zhandler 1 time (sig==20).

So my conclusion is: exec and/or <() invoke zdhandler in such a way,
that it masks SIGINT.

That said, full Zsh with Fast-Syntax-Highlighting is needed for the
effect of Ctrl-C blockage to occur, in zsh -f I can repeat zhandler
invocations, but Ctrl-C still works.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin