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

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

Signal 20 is CHLD. I deferred sending this signal by <( echo test;
sleep 15 ) – the `sleep' here. So zhandler() isn't called when exec <
<() runs. I then test pressing of Ctrl-C. But, again: INT is
apparently masked, as both debugger and Zsh don't react to Ctrl-C. So
it's not zhandler that masks INT (it's called ~15 seconds after I test
Ctrl-C).

So what can mask SIGINT?

On 7 July 2018 at 16:48, Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx> wrote:
> 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



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