help needed to fix contrib/ee crash/exit when receiving SIGWINCH

[Alexander Best]

hi everyone,

together with hugh mahon (the author of ee) i've been trying to fix a nasty
bug in ee. for some reason ee exits (not crashes) and leaves the console
corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all
running ee instances).

unfortunately we were unable to find the problem. it seems to be related to
ncurses. running the ee linux binary under freebsd causes no problem with
SIGWINCH at all. since the linux binary doesn't need to be linked against
ncurses (linux has termio.h/sgtty.h) we assume the problem is related to
ncurses.

right at the beginning of the ee code all signals get set to SIG_IGN:

        for (counter = 1; counter <= 32; counter++)
                signal(counter, SIG_IGN);

so actually SIGWINCH shouldn't cause any problems since it gets discarded.
looking through the src i'm quite sure that SIGWINCH stays set to SIG_IGN the
whole time.

yet running ee with truss shows this result when doing `grep WINCH`:

sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigaction(SIGWINCH,{ SIG_IGN SA_RESTART ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
sigaction(SIGWINCH,0x0,{ SIG_IGN SA_RESTART ss_t }) = 0 (0x0)
sigaction(SIGWINCH,{ 0x280bc130 0x0 ss_t },0x0)  = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)

so SIGWINCH doesn't stay set to SIG_IGN the whole time. it seems the problem
is being caused by some ncurses function which gets called in contrib/ee/ee.c.

contrib/ee/new_curse* aren't used since ee relies in freebsd's local ncurse
implementation.

it would be really great if this nasty bug could be fixed. you'll find a
problem report here: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/136223

please don't hesitate to ask for more details.

cheers.
alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Antony Mawer-14]

On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
<alexbestms@...> wrote:
> hi everyone,
>
> together with hugh mahon (the author of ee) i've been trying to fix a nasty
> bug in ee. for some reason ee exits (not crashes) and leaves the console
> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all
> running ee instances).

I noticed this the other day when working on a new 8.0-RC1 system...
in my case I was using putty (Windows ssh client) to access the system
and maximised the window I had ee running in, and noticed ee just
dumped me straight to the prompt.

I am wondering if this has anything to do with the new tty subsystem
in 8.0, as this wasn't a problem I've experienced before under 7.x...

Maybe worth cc'ing ed@ to see if he has any thoughts?

--Antony
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Nate Eldredge-4]

On Fri, 23 Oct 2009, Antony Mawer wrote:

> On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> <alexbestms@...> wrote:
>> hi everyone,
>>
>> together with hugh mahon (the author of ee) i've been trying to fix a nasty
>> bug in ee. for some reason ee exits (not crashes) and leaves the console
>> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all
>> running ee instances).
>
> I noticed this the other day when working on a new 8.0-RC1 system...
> in my case I was using putty (Windows ssh client) to access the system
> and maximised the window I had ee running in, and noticed ee just
> dumped me straight to the prompt.

Seems a good start might be to compile ncurses with -g, link ee against
it, put a breakpoint on the SIGWINCH handler, and start single stepping...

--

Nate Eldredge
nate@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Joel Dahl]

Antony Mawer skrev:

> On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> <alexbestms@...> wrote:
>> hi everyone,
>>
>> together with hugh mahon (the author of ee) i've been trying to fix a nasty
>> bug in ee. for some reason ee exits (not crashes) and leaves the console
>> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all
>> running ee instances).
>
> I noticed this the other day when working on a new 8.0-RC1 system...
> in my case I was using putty (Windows ssh client) to access the system
> and maximised the window I had ee running in, and noticed ee just
> dumped me straight to the prompt.
>
> I am wondering if this has anything to do with the new tty subsystem
> in 8.0, as this wasn't a problem I've experienced before under 7.x...

I've been using ee in Mac OSX for a while and I see the exact same behaviour,
ee exits when I resize the terminal window.  I haven't seen it in FreeBSD yet,
but that is probably because I don't use Xorg on any of my FreeBSD systems...

--
Joel
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[pluknet]

2009/10/23 Antony Mawer <lists@...>:

> On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> <alexbestms@...> wrote:
>> hi everyone,
>>
>> together with hugh mahon (the author of ee) i've been trying to fix a nasty
>> bug in ee. for some reason ee exits (not crashes) and leaves the console
>> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all
>> running ee instances).
>
> I noticed this the other day when working on a new 8.0-RC1 system...
> in my case I was using putty (Windows ssh client) to access the system
> and maximised the window I had ee running in, and noticed ee just
> dumped me straight to the prompt.
>
> I am wondering if this has anything to do with the new tty subsystem
> in 8.0, as this wasn't a problem I've experienced before under 7.x...
>

No, that's a regression appeared in (FreeBSD'ish? version of) ee 1.5.0.

--
wbr,
pluknet
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

Nate Eldredge schrieb am 2009-10-23:
> On Fri, 23 Oct 2009, Antony Mawer wrote:

> >On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> ><alexbestms@...> wrote:
> >>hi everyone,

> >>together with hugh mahon (the author of ee) i've been trying to
> >>fix a nasty
> >>bug in ee. for some reason ee exits (not crashes) and leaves the
> >>console
> >>corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should
> >>exit all
> >>running ee instances).

> >I noticed this the other day when working on a new 8.0-RC1 system...
> >in my case I was using putty (Windows ssh client) to access the
> >system
> >and maximised the window I had ee running in, and noticed ee just
> >dumped me straight to the prompt.

> Seems a good start might be to compile ncurses with -g, link ee
> against it, put a breakpoint on the SIGWINCH handler, and start
> single stepping...

> --

> Nate Eldredge
> nate@...

it seems ncurses registers a standard libc function with SIGWINCH. i started
gdb, loaded ee and did "handle SIGWINCH stop"

when i do "run" and issue a SIGWINCH to ee this is the output:

Program received signal SIGWINCH, Window size changed.
0x281a4063 in read () from /lib/libc.so.7

(gdb) nexti
0x281a4048 in write () from /lib/libc.so.7
(gdb) nexti
0x281a4049 in write () from /lib/libc.so.7
(gdb) nexti
0x281a404e in write () from /lib/libc.so.7
(gdb) nexti
0x281a404f in write () from /lib/libc.so.7
(gdb) nexti
0x281a4055 in write () from /lib/libc.so.7
(gdb) nexti

Program exited normally.

so i guess ee calls some ncurses function right at the beginning. that ncurses
function registers a new function to be called upon SIGWINCH (maybe exit(3)).

cheers.
alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

pluknet schrieb am 2009-10-23:
> 2009/10/23 Antony Mawer <lists@...>:
> > On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> > <alexbestms@...> wrote:
> >> hi everyone,

> >> together with hugh mahon (the author of ee) i've been trying to
> >> fix a nasty
> >> bug in ee. for some reason ee exits (not crashes) and leaves the
> >> console
> >> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should
> >> exit all
> >> running ee instances).

> > I noticed this the other day when working on a new 8.0-RC1
> > system...
> > in my case I was using putty (Windows ssh client) to access the
> > system
> > and maximised the window I had ee running in, and noticed ee just
> > dumped me straight to the prompt.

> > I am wondering if this has anything to do with the new tty
> > subsystem
> > in 8.0, as this wasn't a problem I've experienced before under
> > 7.x...


> No, that's a regression appeared in (FreeBSD'ish? version of) ee
> 1.5.0.

i'm not so sure this is entirely ee's fault. i just grabbed a really ancient
version of ee from http://www.anerd.org/sources/ (ee-1.4.2.src.tgz last
modified Jan 2001).

yet i see the very same behaviour as with ee 1.5.0. right now it looks more
like a tty or ncurses bug.

cheers.
alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Paul B Mahol]

On 10/23/09, Alexander Best <alexbestms@...> wrote:

> Nate Eldredge schrieb am 2009-10-23:
>> On Fri, 23 Oct 2009, Antony Mawer wrote:
>
>> >On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
>> ><alexbestms@...> wrote:
>> >>hi everyone,
>
>> >>together with hugh mahon (the author of ee) i've been trying to
>> >>fix a nasty
>> >>bug in ee. for some reason ee exits (not crashes) and leaves the
>> >>console
>> >>corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should
>> >>exit all
>> >>running ee instances).
>
>> >I noticed this the other day when working on a new 8.0-RC1 system...
>> >in my case I was using putty (Windows ssh client) to access the
>> >system
>> >and maximised the window I had ee running in, and noticed ee just
>> >dumped me straight to the prompt.
>
>> Seems a good start might be to compile ncurses with -g, link ee
>> against it, put a breakpoint on the SIGWINCH handler, and start
>> single stepping...
>
>> --
>
>> Nate Eldredge
>> nate@...
>
> it seems ncurses registers a standard libc function with SIGWINCH. i started
> gdb, loaded ee and did "handle SIGWINCH stop"
>
> when i do "run" and issue a SIGWINCH to ee this is the output:
>
> Program received signal SIGWINCH, Window size changed.
> 0x281a4063 in read () from /lib/libc.so.7
>
> (gdb) nexti
> 0x281a4048 in write () from /lib/libc.so.7
> (gdb) nexti
> 0x281a4049 in write () from /lib/libc.so.7
> (gdb) nexti
> 0x281a404e in write () from /lib/libc.so.7
> (gdb) nexti
> 0x281a404f in write () from /lib/libc.so.7
> (gdb) nexti
> 0x281a4055 in write () from /lib/libc.so.7
> (gdb) nexti
>
> Program exited normally.
>
> so i guess ee calls some ncurses function right at the beginning. that
> ncurses
> function registers a new function to be called upon SIGWINCH (maybe
> exit(3)).

Hmm, from my little experience with ncurses, there is no such function bind to
SIGWINCH. Even if exit() is called from ncurses that's because ncurses can not
handle current state in any reasonable way so exiting is only possible solution,
but in such case something should be printed and program should not
exit normally.

If you start another shell command from ee, and let it be for example vim, once
you resize xterm window, vim will still work but ee will start to
consume CPU time.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Gary Jennejohn-3]

On Fri, 23 Oct 2009 12:58:43 +0400
pluknet <pluknet@...> wrote:

> 2009/10/23 Antony Mawer <lists@...>:
> > On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> > <alexbestms@...> wrote:
> >> hi everyone,
> >>
> >> together with hugh mahon (the author of ee) i've been trying to fix a nasty
> >> bug in ee. for some reason ee exits (not crashes) and leaves the console
> >> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all
> >> running ee instances).
> >
> > I noticed this the other day when working on a new 8.0-RC1 system...
> > in my case I was using putty (Windows ssh client) to access the system
> > and maximised the window I had ee running in, and noticed ee just
> > dumped me straight to the prompt.
> >
> > I am wondering if this has anything to do with the new tty subsystem
> > in 8.0, as this wasn't a problem I've experienced before under 7.x...
> >
>
> No, that's a regression appeared in (FreeBSD'ish? version of) ee 1.5.0.
>

SIGWINCH is handled in new_curse.c, but it's not being compiled/linked.

---
Gary Jennejohn
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Gary Jennejohn-3]

On Fri, 23 Oct 2009 13:50:24 +0200
Gary Jennejohn <gary.jennejohn@...> wrote:

> On Fri, 23 Oct 2009 12:58:43 +0400
> pluknet <pluknet@...> wrote:
>
> > 2009/10/23 Antony Mawer <lists@...>:
> > > On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> > > <alexbestms@...> wrote:
> > >> hi everyone,
> > >>
> > >> together with hugh mahon (the author of ee) i've been trying to fix a nasty
> > >> bug in ee. for some reason ee exits (not crashes) and leaves the console
> > >> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should exit all
> > >> running ee instances).
> > >
> > > I noticed this the other day when working on a new 8.0-RC1 system...
> > > in my case I was using putty (Windows ssh client) to access the system
> > > and maximised the window I had ee running in, and noticed ee just
> > > dumped me straight to the prompt.
> > >
> > > I am wondering if this has anything to do with the new tty subsystem
> > > in 8.0, as this wasn't a problem I've experienced before under 7.x...
> > >
> >
> > No, that's a regression appeared in (FreeBSD'ish? version of) ee 1.5.0.
> >
>
> SIGWINCH is handled in new_curse.c, but it's not being compiled/linked.
>

Never mind - I see that new_curse.c is supposed to be a substitute for
ncurses if it's not available on the system.

Sorry for the noise.

---
Gary Jennejohn
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Dag-Erling Smørgrav]

[cc: ed for ee and rafan for ncurses]

Alexander Best <alexbestms@...> writes:
> i'm not so sure this is entirely ee's fault.

It is *partly* ee's fault.

src/usr.bin/ee/ee.c in 7:

                in = wgetch(text_win);
                if (in == -1)
                        continue;

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.

so ee is not portable (it should not assume that a "handled signal" such
as SIGWINCH does not interrupt wgetch()), but that's not the real issue.

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.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

Gary Jennejohn schrieb am 2009-10-23:
> On Fri, 23 Oct 2009 12:58:43 +0400
> pluknet <pluknet@...> wrote:

> > 2009/10/23 Antony Mawer <lists@...>:
> > > On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> > > <alexbestms@...> wrote:
> > >> hi everyone,

> > >> together with hugh mahon (the author of ee) i've been trying to
> > >> fix a nasty
> > >> bug in ee. for some reason ee exits (not crashes) and leaves the
> > >> console
> > >> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should
> > >> exit all
> > >> running ee instances).

> > > I noticed this the other day when working on a new 8.0-RC1
> > > system...
> > > in my case I was using putty (Windows ssh client) to access the
> > > system
> > > and maximised the window I had ee running in, and noticed ee just
> > > dumped me straight to the prompt.

> > > I am wondering if this has anything to do with the new tty
> > > subsystem
> > > in 8.0, as this wasn't a problem I've experienced before under
> > > 7.x...


> > No, that's a regression appeared in (FreeBSD'ish? version of) ee
> > 1.5.0.


> SIGWINCH is handled in new_curse.c, but it's not being
> compiled/linked.

> ---
> Gary Jennejohn

i think that file is only used on systems which have termio.h/sgtty.h and ee
doesn't get linked against ncurses. on those systems (linux e.g.) new_curse.c
is used to handle certain things which ncurses takes care under freebsd.

this is under freebsd:

`make`:
Neither termio.h or sgtty.h are on this system!
Relying on local curses implementation.
Generating make.local
make -f make.local
cc ee.c -o ee -ggdb -DDIAG -DHAS_UNISTD -DHAS_STDARG -DHAS_STDLIB -DHAS_CTYPE
-DHAS_SYS_IOCTL -DHAS_SYS_WAIT   -DSLCT_HDR
-DTERMCAP="\"/usr/share/misc/termcap\"" -lcursesw

`ldd ee`:
libncursesw.so.8 => /lib/libncursesw.so.8 (0x2809b000)
libc.so.7 => /lib/libc.so.7 (0x280e9000)

and under linux:

`make`:
Generating make.local
make -f make.local
make[1]: Entering directory `/easyedit-test'
cc -c ee.c -DSYS5  -DBSD_SELECT   -DNCURSE  -DHAS_UNISTD  -DHAS_STDLIB
-DHAS_CTYPE -DHAS_SYS_IOCTL -DHAS_SYS_WAIT   -DSLCT_HDR -s
cc new_curse.c -c -DSYS5  -DBSD_SELECT   -DNCURSE  -DHAS_UNISTD  -DHAS_STDLIB
-DHAS_CTYPE -DHAS_SYS_IOCTL -DHAS_SYS_WAIT   -DSLCT_HDR -s
cc -o ee ee.o new_curse.o -DHAS_UNISTD  -DHAS_STDLIB -DHAS_CTYPE
-DHAS_SYS_IOCTL -DHAS_SYS_WAIT   -DSLCT_HDR -s
make[1]: Leaving directory `/easyedit-test'

`ldd ee`:
libc.so.6 => /lib/libc.so.6 (0x2807a000)
/lib/ld-linux.so.2 (0x2805b000)

alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

Gary Jennejohn schrieb am 2009-10-23:
> On Fri, 23 Oct 2009 12:58:43 +0400
> pluknet <pluknet@...> wrote:

> > 2009/10/23 Antony Mawer <lists@...>:
> > > On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> > > <alexbestms@...> wrote:
> > >> hi everyone,

> > >> together with hugh mahon (the author of ee) i've been trying to
> > >> fix a nasty
> > >> bug in ee. for some reason ee exits (not crashes) and leaves the
> > >> console
> > >> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should
> > >> exit all
> > >> running ee instances).

> > > I noticed this the other day when working on a new 8.0-RC1
> > > system...
> > > in my case I was using putty (Windows ssh client) to access the
> > > system
> > > and maximised the window I had ee running in, and noticed ee just
> > > dumped me straight to the prompt.

> > > I am wondering if this has anything to do with the new tty
> > > subsystem
> > > in 8.0, as this wasn't a problem I've experienced before under
> > > 7.x...


> > No, that's a regression appeared in (FreeBSD'ish? version of) ee
> > 1.5.0.


> SIGWINCH is handled in new_curse.c, but it's not being
> compiled/linked.

> ---
> Gary Jennejohn

i just tried building ee under linux without using new_curse.c and linking the
executable against ncurses. running the binary is showing the same problems
with SIGWINCH. so if this is in fact caused by a ncurses bug the bug appears
in linux ncurses too.

alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[pluknet]

2009/10/23 Alexander Best <alexbestms@...>:

> Gary Jennejohn schrieb am 2009-10-23:
>> On Fri, 23 Oct 2009 12:58:43 +0400
>> pluknet <pluknet@...> wrote:
>
>> > 2009/10/23 Antony Mawer <lists@...>:
>> > > On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
>> > > <alexbestms@...> wrote:
>> > >> hi everyone,
>
>> > >> together with hugh mahon (the author of ee) i've been trying to
>> > >> fix a nasty
>> > >> bug in ee. for some reason ee exits (not crashes) and leaves the
>> > >> console
>> > >> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee` should
>> > >> exit all
>> > >> running ee instances).
>
>> > > I noticed this the other day when working on a new 8.0-RC1
>> > > system...
>> > > in my case I was using putty (Windows ssh client) to access the
>> > > system
>> > > and maximised the window I had ee running in, and noticed ee just
>> > > dumped me straight to the prompt.
>
>> > > I am wondering if this has anything to do with the new tty
>> > > subsystem
>> > > in 8.0, as this wasn't a problem I've experienced before under
>> > > 7.x...
>
>
>> > No, that's a regression appeared in (FreeBSD'ish? version of) ee
>> > 1.5.0.
>
>
>> SIGWINCH is handled in new_curse.c, but it's not being
>> compiled/linked.
>
>> ---
>> Gary Jennejohn
>
> i think that file is only used on systems which have termio.h/sgtty.h and ee
> doesn't get linked against ncurses. on those systems (linux e.g.) new_curse.c
> is used to handle certain things which ncurses takes care under freebsd.
>
> this is under freebsd:
>
> `make`:
> Neither termio.h or sgtty.h are on this system!
> Relying on local curses implementation.
> Generating make.local
> make -f make.local
> cc ee.c -o ee -ggdb -DDIAG -DHAS_UNISTD -DHAS_STDARG -DHAS_STDLIB -DHAS_CTYPE
> -DHAS_SYS_IOCTL -DHAS_SYS_WAIT   -DSLCT_HDR
> -DTERMCAP="\"/usr/share/misc/termcap\"" -lcursesw
>
> `ldd ee`:
> libncursesw.so.8 => /lib/libncursesw.so.8 (0x2809b000)
> libc.so.7 => /lib/libc.so.7 (0x280e9000)
>

[Probably already mentioned.]

btw, ee compiled under fbsd with new_curse.c
(and not linked with curses/cursesw) goes fine with SIGWINCH.

--- Makefile.old        2009-10-23 16:13:45.000000000 +0400
+++ Makefile    2009-10-23 16:30:03.000000000 +0400
@@ -3,15 +3,14 @@
 .PATH: ${.CURDIR}/../../contrib/ee

 CFLAGS+= -DHAS_NCURSES -DHAS_UNISTD -DHAS_STDARG -DHAS_STDLIB \
-        -DHAS_SYS_WAIT
+        -DHAS_SYS_WAIT -DCAP -DNCURSE

 PROG=  ee
+SRCS=  ee.c new_curse.c
 LINKS= ${BINDIR}/ee ${BINDIR}/ree ${BINDIR}/ee ${BINDIR}/edit
 MLINKS=        ee.1 ree.1 ee.1 edit.1
-DPADD= ${LIBNCURSES}
-LDADD= -lncurses

-WARNS?=        2
+WARNS?=        0

 NLS=   en_US.US-ASCII fr_FR.ISO8859-1 de_DE.ISO8859-1 pl_PL.ISO8859-2 \
        uk_UA.KOI8-U ru_RU.KOI8-R hu_HU.ISO8859-2

$ ldd ./ee
./ee:
        libc.so.6 => /lib/libc.so.6 (0x2808a000)

(yes, it's FreeBSD 6.x).

--
wbr,
pluknet
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

pluknet schrieb am 2009-10-23:
> 2009/10/23 Alexander Best <alexbestms@...>:
> > Gary Jennejohn schrieb am 2009-10-23:
> >> On Fri, 23 Oct 2009 12:58:43 +0400
> >> pluknet <pluknet@...> wrote:

> >> > 2009/10/23 Antony Mawer <lists@...>:
> >> > > On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
> >> > > <alexbestms@...> wrote:
> >> > >> hi everyone,

> >> > >> together with hugh mahon (the author of ee) i've been trying
> >> > >> to
> >> > >> fix a nasty
> >> > >> bug in ee. for some reason ee exits (not crashes) and leaves
> >> > >> the
> >> > >> console
> >> > >> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee`
> >> > >> should
> >> > >> exit all
> >> > >> running ee instances).

> >> > > I noticed this the other day when working on a new 8.0-RC1
> >> > > system...
> >> > > in my case I was using putty (Windows ssh client) to access
> >> > > the
> >> > > system
> >> > > and maximised the window I had ee running in, and noticed ee
> >> > > just
> >> > > dumped me straight to the prompt.

> >> > > I am wondering if this has anything to do with the new tty
> >> > > subsystem
> >> > > in 8.0, as this wasn't a problem I've experienced before under
> >> > > 7.x...


> >> > No, that's a regression appeared in (FreeBSD'ish? version of) ee
> >> > 1.5.0.


> >> SIGWINCH is handled in new_curse.c, but it's not being
> >> compiled/linked.

> >> ---
> >> Gary Jennejohn

> > i think that file is only used on systems which have
> > termio.h/sgtty.h and ee
> > doesn't get linked against ncurses. on those systems (linux e.g.)
> > new_curse.c
> > is used to handle certain things which ncurses takes care under
> > freebsd.

> > this is under freebsd:

> > `make`:
> > Neither termio.h or sgtty.h are on this system!
> > Relying on local curses implementation.
> > Generating make.local
> > make -f make.local
> > cc ee.c -o ee -ggdb -DDIAG -DHAS_UNISTD -DHAS_STDARG -DHAS_STDLIB
> > -DHAS_CTYPE
> > -DHAS_SYS_IOCTL -DHAS_SYS_WAIT   -DSLCT_HDR
> > -DTERMCAP="\"/usr/share/misc/termcap\"" -lcursesw

> > `ldd ee`:
> > libncursesw.so.8 => /lib/libncursesw.so.8 (0x2809b000)
> > libc.so.7 => /lib/libc.so.7 (0x280e9000)


> [Probably already mentioned.]

> btw, ee compiled under fbsd with new_curse.c
> (and not linked with curses/cursesw) goes fine with SIGWINCH.

> --- Makefile.old        2009-10-23 16:13:45.000000000 +0400
> +++ Makefile    2009-10-23 16:30:03.000000000 +0400
> @@ -3,15 +3,14 @@
>  .PATH: ${.CURDIR}/../../contrib/ee

>  CFLAGS+= -DHAS_NCURSES -DHAS_UNISTD -DHAS_STDARG -DHAS_STDLIB \
> -        -DHAS_SYS_WAIT
> +        -DHAS_SYS_WAIT -DCAP -DNCURSE

>  PROG=  ee
> +SRCS=  ee.c new_curse.c
>  LINKS= ${BINDIR}/ee ${BINDIR}/ree ${BINDIR}/ee ${BINDIR}/edit
>  MLINKS=        ee.1 ree.1 ee.1 edit.1
> -DPADD= ${LIBNCURSES}
> -LDADD= -lncurses

> -WARNS?=        2
> +WARNS?=        0

>  NLS=   en_US.US-ASCII fr_FR.ISO8859-1 de_DE.ISO8859-1
>  pl_PL.ISO8859-2 \
>         uk_UA.KOI8-U ru_RU.KOI8-R hu_HU.ISO8859-2

> $ ldd ./ee
> ./ee:
>         libc.so.6 => /lib/libc.so.6 (0x2808a000)

> (yes, it's FreeBSD 6.x).

won't work under CURRENT i'm afraid:

Warning: Object directory not changed from original /usr/src/usr.bin/ee
cc  -O2 -fno-strict-aliasing -pipe -march=native -DHAS_NCURSES -DHAS_UNISTD
-DHAS_STDARG -DHAS_STDLIB  -DHAS_SYS_WAIT -DCAP -DNCURSE -std=gnu99
-fstack-protector -Wno-pointer-sign -c
/usr/src/usr.bin/ee/../../contrib/ee/ee.c
In file included from /usr/src/usr.bin/ee/../../contrib/ee/ee.c:68:
/usr/src/usr.bin/ee/../../contrib/ee/new_curse.h:47:19: error: sgtty.h: No
such file or directory
*** Error code 1

Stop in /usr/src/usr.bin/ee.

here's the entry in ObsoleteFiles.inc:

# 20080725: sgtty.h removed
OLD_FILES+=usr/include/sgtty.h

alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[pluknet]

2009/10/23 Alexander Best <alexbestms@...>:

> pluknet schrieb am 2009-10-23:
>> 2009/10/23 Alexander Best <alexbestms@...>:
>> > Gary Jennejohn schrieb am 2009-10-23:
>> >> On Fri, 23 Oct 2009 12:58:43 +0400
>> >> pluknet <pluknet@...> wrote:
>
>> >> > 2009/10/23 Antony Mawer <lists@...>:
>> >> > > On Fri, Oct 23, 2009 at 1:35 PM, Alexander Best
>> >> > > <alexbestms@...> wrote:
>> >> > >> hi everyone,
>
>> >> > >> together with hugh mahon (the author of ee) i've been trying
>> >> > >> to
>> >> > >> fix a nasty
>> >> > >> bug in ee. for some reason ee exits (not crashes) and leaves
>> >> > >> the
>> >> > >> console
>> >> > >> corrupted when receiving SIGWINCH (`killall -SIGWINCH ee`
>> >> > >> should
>> >> > >> exit all
>> >> > >> running ee instances).
>
>> >> > > I noticed this the other day when working on a new 8.0-RC1
>> >> > > system...
>> >> > > in my case I was using putty (Windows ssh client) to access
>> >> > > the
>> >> > > system
>> >> > > and maximised the window I had ee running in, and noticed ee
>> >> > > just
>> >> > > dumped me straight to the prompt.
>
>> >> > > I am wondering if this has anything to do with the new tty
>> >> > > subsystem
>> >> > > in 8.0, as this wasn't a problem I've experienced before under
>> >> > > 7.x...
>
>
>> >> > No, that's a regression appeared in (FreeBSD'ish? version of) ee
>> >> > 1.5.0.
>
>
>> >> SIGWINCH is handled in new_curse.c, but it's not being
>> >> compiled/linked.
>
>> >> ---
>> >> Gary Jennejohn
>
>> > i think that file is only used on systems which have
>> > termio.h/sgtty.h and ee
>> > doesn't get linked against ncurses. on those systems (linux e.g.)
>> > new_curse.c
>> > is used to handle certain things which ncurses takes care under
>> > freebsd.
>
>> > this is under freebsd:
>
>> > `make`:
>> > Neither termio.h or sgtty.h are on this system!
>> > Relying on local curses implementation.
>> > Generating make.local
>> > make -f make.local
>> > cc ee.c -o ee -ggdb -DDIAG -DHAS_UNISTD -DHAS_STDARG -DHAS_STDLIB
>> > -DHAS_CTYPE
>> > -DHAS_SYS_IOCTL -DHAS_SYS_WAIT   -DSLCT_HDR
>> > -DTERMCAP="\"/usr/share/misc/termcap\"" -lcursesw
>
>> > `ldd ee`:
>> > libncursesw.so.8 => /lib/libncursesw.so.8 (0x2809b000)
>> > libc.so.7 => /lib/libc.so.7 (0x280e9000)
>
>
>> [Probably already mentioned.]
>
>> btw, ee compiled under fbsd with new_curse.c
>> (and not linked with curses/cursesw) goes fine with SIGWINCH.
>
>> --- Makefile.old        2009-10-23 16:13:45.000000000 +0400
>> +++ Makefile    2009-10-23 16:30:03.000000000 +0400
>> @@ -3,15 +3,14 @@
>>  .PATH: ${.CURDIR}/../../contrib/ee
>
>>  CFLAGS+= -DHAS_NCURSES -DHAS_UNISTD -DHAS_STDARG -DHAS_STDLIB \
>> -        -DHAS_SYS_WAIT
>> +        -DHAS_SYS_WAIT -DCAP -DNCURSE
>
>>  PROG=  ee
>> +SRCS=  ee.c new_curse.c
>>  LINKS= ${BINDIR}/ee ${BINDIR}/ree ${BINDIR}/ee ${BINDIR}/edit
>>  MLINKS=        ee.1 ree.1 ee.1 edit.1
>> -DPADD= ${LIBNCURSES}
>> -LDADD= -lncurses
>
>> -WARNS?=        2
>> +WARNS?=        0
>
>>  NLS=   en_US.US-ASCII fr_FR.ISO8859-1 de_DE.ISO8859-1
>>  pl_PL.ISO8859-2 \
>>         uk_UA.KOI8-U ru_RU.KOI8-R hu_HU.ISO8859-2
>
>> $ ldd ./ee
>> ./ee:
>>         libc.so.6 => /lib/libc.so.6 (0x2808a000)
>
>> (yes, it's FreeBSD 6.x).
>
> won't work under CURRENT i'm afraid:
>
> Warning: Object directory not changed from original /usr/src/usr.bin/ee
> cc  -O2 -fno-strict-aliasing -pipe -march=native -DHAS_NCURSES -DHAS_UNISTD
> -DHAS_STDARG -DHAS_STDLIB  -DHAS_SYS_WAIT -DCAP -DNCURSE -std=gnu99
> -fstack-protector -Wno-pointer-sign -c
> /usr/src/usr.bin/ee/../../contrib/ee/ee.c
> In file included from /usr/src/usr.bin/ee/../../contrib/ee/ee.c:68:
> /usr/src/usr.bin/ee/../../contrib/ee/new_curse.h:47:19: error: sgtty.h: No
> such file or directory
> *** Error code 1
>
> Stop in /usr/src/usr.bin/ee.
>
> here's the entry in ObsoleteFiles.inc:
>
> # 20080725: sgtty.h removed
> OLD_FILES+=usr/include/sgtty.h
>
> alex
>

Ah, OK. Just a stupid and not-tested guess.


--
wbr,
pluknet
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Eygene Ryabinkin-3]

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
    {_.-``-'         {_/            #

---

From d0b09b188c778858f44379546bcce05e8a279fe0 Mon Sep 17 00:00:00 2001
From: Eygene Ryabinkin <rea-fbsd@...>
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 = 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@...>
---
 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/ncurses/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 = 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) == -1)
+    fifo_pull(sp);
  returnCode(*result >= KEY_MIN ? KEY_CODE_YES : OK);
     }
  }
--
1.6.4.4

---

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

Eygene Ryabinkin schrieb am 2009-10-23:
> 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?

thanks a million. for me the patch works great. :) the sooner it gets
committed the better. ;) since this problem is not limited to freebsd it would
be nice if somebody could send the patch to the ncurses maintainers so all
OSes using ncurses can profit from it.

cheers.
alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Eygene Ryabinkin-3]

Fri, Oct 23, 2009 at 06:32:38PM +0200, Alexander Best wrote:
> thanks a million. for me the patch works great. :)

You're welcome ;))

> the sooner it gets committed the better. ;)

It may well break something else.  I am not 100% sure that this patch
is the proper thing -- curses code is a bit new to me, so I would say
that the patch will need more thorough review from maintainers.

> since this problem is not limited to freebsd it would be nice if
> somebody could send the patch to the ncurses maintainers so all OSes
> using ncurses can profit from it.

Will also send this patch to bug-ncurses@....
--
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook
    {_.-``-'         {_/            #
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alexander Best]

Eygene Ryabinkin schrieb am 2009-10-23:
> 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?

oh...and btw. the PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/136223)
hasn't been assigned to anyone yet. could the person who will be committing
the patch please take care of that (maybe setting the PR to
analysed->patched->closed? ;) would be great if this fix could make it into
8.0-RELEASE in time because it's quite nasty to lose all your editor data due
to a SIGWINCH.

cheers.
alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."