From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
To: Peter Stephenson <p.stephenson@samsung.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [BUG] Ctrl-C stops working after process substitution
Date: Tue, 10 Jul 2018 17:06:42 +0200 [thread overview]
Message-ID: <CAKc7PVBPsVJYgWmqCo=wtHNmUfQzXsb7vZzbuRH4KXig7fMcDQ@mail.gmail.com> (raw)
In-Reply-To: <CAKc7PVDk1SFj8QopEZLkEo997O3NwmUP6cXRHd_4_cakSbTmLw@mail.gmail.com>
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@gmail.com> wrote:
> On 5 July 2018 at 10:44, Peter Stephenson <p.stephenson@samsung.com> 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
next prev parent reply other threads:[~2018-07-10 15:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-04 11:47 Sebastian Gniazdowski
2018-07-04 12:09 ` Daniel Shahaf
2018-07-04 17:07 ` Sebastian Gniazdowski
2018-07-05 8:44 ` Peter Stephenson
2018-07-07 13:03 ` Sebastian Gniazdowski
2018-07-07 13:18 ` Sebastian Gniazdowski
2018-07-07 14:48 ` Sebastian Gniazdowski
2018-07-10 15:06 ` Sebastian Gniazdowski [this message]
2018-07-10 15:21 ` Peter Stephenson
2018-07-10 17:57 ` Sebastian Gniazdowski
2018-07-11 8:48 ` Sebastian Gniazdowski
2018-07-11 10:07 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKc7PVBPsVJYgWmqCo=wtHNmUfQzXsb7vZzbuRH4KXig7fMcDQ@mail.gmail.com' \
--to=sgniazdowski@gmail.com \
--cc=p.stephenson@samsung.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).