From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Where to start debugging zle recursive-edit? / Ctrl-C
Date: Fri, 30 Sep 2016 13:28:55 +0200 [thread overview]
Message-ID: <CAKc7PVCvear=ZCOYB+ODYcw+qV8YGbcsLH_arXCFdNMRgJ4O2Q@mail.gmail.com> (raw)
In-Reply-To: <160924133140.ZM29034@torch.brasslantern.com>
[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]
On 24 September 2016 at 22:31, Bart Schaefer <schaefer@brasslantern.com> wrote:
> You're probably interested in getbyte() in zle_main.c, but you might
> also attach with a debugger and put a breakpoint in zhandler so you
> can get a stack trace of where the handler is being called [if it is].
> (Starting the debugger first and running zsh inside it won't work as
> well because the debugger itself will trap the signals).
It turned out that lldb stops at Ctrl-C even without b zhandler and
this is what I've been receiving. The stack trace is at the end.
But I've catched another thing. After Ctrl-C in .recursiveedit the
timeouts at select() in raw_getbyte() stop occuring. Here is simple
video that very well covers this. It shows debug prints stop appearing
(attached 10-context lines diff). And Zconvey stops working, i.e.
sched doesn't call its functions:
https://asciinema.org/a/7s5dofinxlnn1i80ojunzybp7
----------------- BT 10 / LLDB ----------------
(lldb) bt 10
* thread #1: tid = 0x1c441b, 0x00007fff897b107a
libsystem_kernel.dylib`__select + 10, queue = 'com.apple.main-thread',
stop reason = signal SIGINT
* frame #0: 0x00007fff897b107a libsystem_kernel.dylib`__select + 10
frame #1: 0x00000001082b70e0 zle.so`raw_getbyte(do_keytmout=0,
cptr="") + 640 at zle_main.c:615
frame #2: 0x00000001082b6abf zle.so`getbyte(do_keytmout=0,
timeout=0x0000000000000000) + 319 at zle_main.c:893
frame #3: 0x00000001082b5798 zle.so`getkeybuf(w=0) + 24 at zle_keymap.c:1663
frame #4: 0x00000001082b54b6
zle.so`getkeymapcmd(km=0x00007fbe3201ce00, funcp=0x00007fff57c81c10,
strp=0x00007fff57c81bf8) + 102 at zle_keymap.c:1581
frame #5: 0x00000001082b5903 zle.so`getkeycmd + 35 at zle_keymap.c:1692
frame #6: 0x00000001082b8430 zle.so`zlecore + 320 at zle_main.c:1136
frame #7: 0x00000001082b951b
zle.so`recursiveedit(args=0x00000001083d3a00) + 27 at zle_main.c:1903
frame #8: 0x00000001082b7ea2
zle.so`execzlefunc(func=0x00000001082ea408, args=0x00000001083d3a00,
set_bindk=1) + 770 at zle_main.c:1455
[-- Attachment #2: rec2_edit.2.diff.txt --]
[-- Type: text/plain, Size: 4228 bytes --]
diff --git a/Src/Zle/zle_main.c b/Src/Zle/zle_main.c
index 9a83d41..7f3da8d 100644
--- a/Src/Zle/zle_main.c
+++ b/Src/Zle/zle_main.c
@@ -612,31 +612,55 @@ raw_getbyte(long do_keytmout, char *cptr)
tvptr = NULL;
winch_unblock();
selret = select(fdmax+1, (SELECT_ARG_2_T) & foofd,
NULL, NULL, tvptr);
winch_block();
# endif
/*
* Make sure a user interrupt gets passed on straight away.
*/
- if (selret < 0 && (errflag || retflag || breaks || exit_pending))
+ if (selret < 0 && (errflag || retflag || breaks || exit_pending)) {
+ // MY DEBUG
+ FILE *_F = fopen("/tmp/recursive.txt", "a+");
+ fprintf( _F, "-- Doing break / zle_main.c: errflag: %d, retflag: %d, breaks: %d, exit_pending: %d\n",
+ errflag, retflag, breaks, exit_pending );
+ fclose(_F);
break;
+ } else {
+ // MY DEBUG
+ FILE *_F = fopen("/tmp/recursive.txt", "a+");
+ fprintf( _F, "-- NOT doing break / zle_main.c: errflag: %d, retflag: %d, breaks: %d, exit_pending: %d\n",
+ errflag, retflag, breaks, exit_pending );
+ fclose(_F);
+ }
+
/*
* Try to avoid errors on our special fd's from
* messing up reads from the terminal. Try first
* with all fds, then try unsetting the special ones.
*/
if (selret < 0 && !errtry) {
+ // MY DEBUG
+ FILE *_F = fopen("/tmp/recursive.txt", "a+");
+ fprintf( _F, "-- Trying again !errtry / zle_main.c\n" );
+ fclose(_F);
+
errtry = 1;
continue;
- }
+ } else {
+ // MY DEBUG
+ FILE *_F = fopen("/tmp/recursive.txt", "a+");
+ fprintf( _F, "-- Passed !errtry(errtry:%d) / zle_main.c\n", errtry );
+ fclose(_F);
+ }
+
if (selret == 0) {
/*
* Nothing ready and no error, so we timed out.
*/
switch (tmout.tp) {
case ZTM_NONE:
/* keeps compiler happy if not debugging */
#ifdef DEBUG
dputs("BUG: timeout fired with no timeout set.");
#endif
@@ -888,22 +912,36 @@ getbyte(long do_keytmout, int *timeout)
the counter (icnt) so that this happens 20 times and than
the shell gives up (yes, this is a bit dirty...). */
if ((zlereadflags & ZLRF_IGNOREEOF) && icnt++ < 20)
continue;
stopmsg = 1;
zexit(1, 0);
}
icnt = 0;
if (errno == EINTR) {
die = 0;
+ static int counter = 0;
+
+ // MY DEBUG
+ FILE *_F = fopen("/tmp/recursive.txt", "a+");
+ fprintf( _F, "-- Got EINTR %d\n", ++counter );
+ fclose(_F);
+
if (!errflag && !retflag && !breaks && !exit_pending)
+ {
+ // MY DEBUG
+ FILE *_F = fopen("/tmp/recursive.txt", "a+");
+ fprintf( _F, "-- Continuing despite EINTR / zle_main.c: errflag: %d, retflag: %d, breaks: %d, exit_pending: %d\n",
+ errflag, retflag, breaks, exit_pending );
+ fclose(_F);
continue;
+ }
errflag &= ~ERRFLAG_ERROR;
breaks = obreaks;
errno = old_errno;
return lastchar = EOF;
} else if (errno == EWOULDBLOCK) {
fcntl(0, F_SETFL, 0);
} else if (errno == EIO && !die) {
ret = opts[MONITOR];
opts[MONITOR] = 1;
attachtty(mypgrp);
@@ -1115,20 +1153,24 @@ zlecore(void)
if (eofsent)
break;
}
handleprefixes();
/* for vi mode, make sure the cursor isn't somewhere illegal */
if (invicmdmode() && zlecs > findbol() &&
(zlecs == zlell || zleline[zlecs] == ZWC('\n')))
DECCS();
handleundo();
} else {
+ // MY DEBUG
+ FILE *_F = fopen("/tmp/recursive.txt", "a+");
+ fprintf( _F, "-- Setting error in zlecore.c\n" );
+ fclose(_F);
errflag |= ERRFLAG_ERROR;
break;
}
redrawhook();
#ifdef HAVE_POLL
if (baud && !(lastcmd & ZLE_MENUCMP)) {
struct pollfd pfd;
int to = cost * costmult / 1000; /* milliseconds */
next prev parent reply other threads:[~2016-10-01 22:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-23 16:26 Sebastian Gniazdowski
2016-09-24 20:31 ` Bart Schaefer
2016-09-24 20:58 ` Sebastian Gniazdowski
2016-09-25 7:09 ` Daniel Shahaf
2016-09-26 22:16 ` Sebastian Gniazdowski
2016-09-27 16:09 ` Bart Schaefer
2016-09-29 9:30 ` Sebastian Gniazdowski
2016-09-29 17:07 ` Bart Schaefer
2016-09-30 9:04 ` Sebastian Gniazdowski
2016-09-30 11:28 ` Sebastian Gniazdowski [this message]
2016-09-30 13:30 ` Sebastian Gniazdowski
2016-09-30 20:44 ` Bart Schaefer
2016-10-02 16:26 ` Sebastian Gniazdowski
2016-10-02 17:37 ` Sebastian Gniazdowski
2016-10-05 5:31 ` Sebastian Gniazdowski
2016-10-05 6:14 ` Bart Schaefer
2016-10-05 10:27 ` Sebastian Gniazdowski
2016-10-05 18:31 ` Bart Schaefer
2016-10-05 20:36 ` Sebastian Gniazdowski
2016-09-30 21:45 ` Bart Schaefer
2016-09-30 21:54 ` Sebastian Gniazdowski
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='CAKc7PVCvear=ZCOYB+ODYcw+qV8YGbcsLH_arXCFdNMRgJ4O2Q@mail.gmail.com' \
--to=sgniazdowski@gmail.com \
--cc=schaefer@brasslantern.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).