Date: Fri, 23 Oct 2009 19:56:35 +0400 From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: Dag-Erling Sm??rgrav <des@des.no> Cc: freebsd-hackers@freebsd.org, pluknet <pluknet@gmail.com>, ed@freebsd.org, Antony Mawer <lists@mawer.org>, Alexander Best <alexbestms@math.uni-muenster.de>, rafan@freebsd.org Subject: Re: help needed to fix contrib/ee crash/exit when receiving SIGWINCH Message-ID: <8gJJDa6kRsCUwxK/zidtHIOFMRw@LbQSLh99U4wa807TkC1GazBU7WI> In-Reply-To: <86tyxqqpwh.fsf@ds4.des.no> References: <permail-20091023104227f0889e8400002915-a_best01@message-id.uni-muenster.de> <86tyxqqpwh.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Gentlemen, good day.
Fri, Oct 23, 2009 at 02:02:38PM +0200, Dag-Erling Sm??rgrav wrote:
> src/contrib/ee/ee.c in 8:
>
> in = wgetch(text_win);
> if (in == -1)
> exit(0); /* without this exit ee will go into an
> infinite loop if the network
> session detaches */
>
> >From the wgetch() man page:
>
> Programmers concerned about portability should be prepared for
> either of two cases: (a) signal receipt does not interrupt
> getch; (b) signal receipt interrupts getch and causes it to
> return ERR with errno set to EINTR. Under the ncurses
> implementation, handled signals never inter??? rupt getch.
Hmm, we can transform this code to the following one:
-----
errno = 0;
do {
in = wgetch(text_win);
} while (errno == EINTR);
if (in == -1)
exit(0);
-----
This won't help with FreeBSD's ncurses, but may be other variants
will feel much better with such a event loop variant.
> The real issue, though, is that when a SIGWINCH is caught, wgetch()
> correctly returns KEY_RESIZE, but the next call to wgetch() returns -1.
> The next call after that is fine. I suspect the error lies somewhere
> inside kgetch() in contrib/ncurses/ncurses/base/lib_getch.c.
The problem should be healed with the attached patch. And you're
partly right: this is kgetch() that is returning ERR for the second
wgetch(), but kgetch() shouldn't be blamed for this -- _nc_wgetch()
should. At least in my opinion ;)
Any views on this?
--
Eygene
_ ___ _.--. #
\`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard
/ ' ` , __.--' # to read the on-line manual
)/' _/ \ `-_, / # while single-stepping the kernel.
`-'" `"\_ ,_.-;_.-\_ ', fsc/as #
_.-'_./ {_.' ; / # -- FreeBSD Developers handbook
{_.-``-' {_/ #
--+HP7ph2BbKc20aGI
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="ncurses-properly-handle-SIGWINCH.diff"
Content-Transfer-Encoding: quoted-printable
=46rom d0b09b188c778858f44379546bcce05e8a279fe0 Mon Sep 17 00:00:00 2001
=46rom: Eygene Ryabinkin <rea-fbsd@codelabs.ru>
Date: Fri, 23 Oct 2009 19:02:14 +0400
Subject: [PATCH] Ncurses: get ERR from the fifo when SIGWINCH is handled
fifo_pull() will put ERR to the buffer if read() will fail
for any reason. kgetch() will notice this ERR and won't
interpret any fifo contents setting peek =3D head. But when
_nc_wgetch() will handle SIGWINCH and KEY_RESIZE will be
pushed into fifo and taken out, ERR will still stay there.
We should take ERR from the fifo or kgetch() will return
ERR on all subsequent calls.
Signed-off-by: Eygene Ryabinkin <rea-fbsd@codelabs.ru>
---
contrib/ncurses/ncurses/base/lib_getch.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/contrib/ncurses/ncurses/base/lib_getch.c b/contrib/ncurses/ncu=
rses/base/lib_getch.c
index a3812be..e7ba0b2 100644
--- a/contrib/ncurses/ncurses/base/lib_getch.c
+++ b/contrib/ncurses/ncurses/base/lib_getch.c
@@ -476,6 +476,12 @@ _nc_wgetch(WINDOW *win,
/* resizeterm can push KEY_RESIZE */
if (cooked_key_in_fifo()) {
*result =3D fifo_pull(sp);
+ /*
+ * Get the ERR from queue -- it is from WINCH,
+ * so we should take it out, the "error" is handled.
+ */
+ if (fifo_peek(sp) =3D=3D -1)
+ fifo_pull(sp);
returnCode(*result >=3D KEY_MIN ? KEY_CODE_YES : OK);
}
}
--=20
1.6.4.4
--+HP7ph2BbKc20aGI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8gJJDa6kRsCUwxK/zidtHIOFMRw>