nano-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] nano not exiting cleanly bug


From: David Lawrence Ramsey
Subject: Re: [Nano-devel] nano not exiting cleanly bug
Date: Wed, 24 Sep 2003 18:55:58 -0700 (PDT)

David Benbennick:
>On Fri, Sep 5, 2003 at 14:17:11 +0200, Jordi Mallach wrote:
>> > sometimes when the terminal exits unexpectedly (or expectedly for
>> > the user, just not for nano), nano will utilize 100% of the cpu and
>> > sit there until killed
>> I got this report once, I couldn't reproduce.
>
>Here's a way to reproduce it, and a fix.  In an xterm, ssh somewhere,
>run nano.  Suspend with ^Z.  Logout.  (The shell should warn that there
>are stopped jobs.)  The Nano window becomes visible, but it can't hear
>input.
> 
>Now close the xterm.

I can definitely reproduce this with ssh and locally, except for the
nano window's being visible afterwards (the 100% CPU usage is easy to
catch, though).

>Nano is looping around in winio.c:get_ignored_kbinput, with wgetch just
>returning errors.  The problem is a line in nano.c:do_cont I added a
>while ago.  Nano checks for the window being resized, so ends up
>ignoring the SIGHUP.

Good, we finally have an explanation for the problem.

>Here's a patch that takes out that line.

Thanks for the effort, but I'm not sure if that's the best solution to
the underlying problem, especially because nano needs to properly handle
size changes that occur while it's suspended.  nano ignores SIGHUP and
SIGTERM upon de-suspension (which apparently also occurs upon logging
out of the shell that it's running in with it suspended) if you send one
of them to it while it's suspended, and as you've already figured out,
it shouldn't.

In do_suspend(), I've tried assigning handle_hupterm() to act as the
SIGHUP and SIGTERM handler just before nano sends itself SIGSTOP, and
this seems to fix the problem in my preliminary testing.  Comments?

http://pooka_regent.tripod.com/patches/nano/nanohupterm-patch.txt

>Generally, using SIGWINCH and siglongjmp to deal with window resizes is
>bad, since Nano's data could be left in an invalid state.  (Try
>resizing while loading a big file.)

Tried that; got segfault.  Good catch.  To deal with this for the time
being, maybe we could block SIGWINCH when it it's in a potentially
unstable state, and when it's in a potentially stable state (possibly
when it's waiting for input, as that's what it spends most of its time
doing anyway?), use sigpending() to see if there's a pending SIGWINCH
and handle it there if there is?

>Perhaps eventually Nano could start checking for KEY_RESIZE from
>ncurses instead.  But that would be a big job.

There's one problem with using that universally: slang compatibility. 
Slang doesn't appear to define a KEY_RESIZE or equivalent at all.

>DB
>
>P.S.  The autogen.sh script doesn't work for me, and I don't know why. 
>I have
>       autoconf (GNU Autoconf) 2.53
>       automake (GNU automake) 1.6.3
>       gettext (GNU gettext-runtime) 0.12.1
>on a Redhat 8 machine, and autogen.sh fails with the message
>
>aclocal: configure.ac: 276: macro `AM_PATH_GLIB' not found in library
>autoreconf: aclocal failed with exit status: 1
> at /usr/bin/autoreconf line 263

Do you have glib installed?

I had something similar happen to me awhile ago, when I was trying to
compile a version (as opposed to CVS snapshot) of nano.  Without the
file /usr/share/aclocal/glib.m4, which was included in my glib package,
and its definition for AM_PATH_GLIB, I got the same kind of error when
running configure.

Try either temporarily installing glib or copying over the m4 file, and
see if that lets autogen.sh, etc. run properly.


_____________________________________________________________
Sluggy.Net: The Sluggy Freelance Community!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]