bug-ncurses
[Top][All Lists]
Advanced

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

Inconsistent wgetch/SIGWINCH handler behavior


From: Dave Ulrick
Subject: Inconsistent wgetch/SIGWINCH handler behavior
Date: Fri, 3 Jun 2005 10:44:40 -0500 (CDT)

Hi,

I'm developing an ncurses application that supports window resizing. I use the default ncurses SIGWINCH signal handler that queues a KEY_RESIZE key when a window resize event occurs. With ncurses 5.4.5 (Fedora Core 2), my program has no trouble reading the KEY_RESIZE events when it calls wgetch, but with ncurses 5.4.61.3 (SuSE Professional 9.1), wgetch returns ERR with errno EINTR when the user resizes the window. I can work around the problem by using my own SIGWINCH signal handler (adapted from the view.c sample program that ships with ncurses 5.4).

The change log for the SuSE 9.1 RPM contains this recent entry:

* Mon Apr 05 2004 - address@hidden

- Be sure that EINTR from signal is correctly delivered to the
  reading thread. Use weak symbols to get it work even if not
  (p)threaded (bug #37273).

Although my first suspicion was that the SuSE maintainers had somehow broken the default ncurses SIGWINCH behavior, I've built my own ncurses shared library from the ncurses 5.4 tarball and can reproduce the problem by running my application against my self-compiled ncurses library. I've not tried building my own ncurses library under Fedora Core 2. Linux kernels: 2.6.5-7.147 on SuSE 9.1 and 2.6.11-something on FC2.

Oh, one more SuSE 9.1 issue. My app allows the user to display certain text files by using his preferred pager (e.g., less or more). I use code like this to accomplish the call to the pager:

def_prog_mode ();
endwin ();
/* call of function that invokes user's pager */
refresh ();

Additionally, I issue 'signal (SIGPIPE, SIG_IGN)' to prevent my app from being killed with a SIGPIPE if the user exits 'less' with 'q' before viewing the end of the file. This all works perfectly, unless I've done a screen resize, especially a maximize. After some (but not all) resizes, the 'less' screen display can be rather confused. For instance, if I've resized from 80x35 to 131x61, 'less' might display its line count on the bottom line (correctly) and advance the file's line count from page to page as though it knows the correct screen size, but only the first thirty-five or so lines of the screen plus the bottom line are actually visible; the rest of the screen being set to the terminal window's default background. This misbehavior occurs only on my SuSE 9.1 system; it never occurs on the FC2 system.

On both systems, ncurses apps such as pine and less (when invoked from a shell prompt) exhibit correct dynamic resizing behavior, and lynx will usually resize itself after a key is pressed subsequent to the resize.

At this point, I'm thinking that I've got one of two situations: (1) my app is correctly using documented ncurses features but my SuSE 9.1 system has something awry that's causing my app to malfunction or (2) my app is inadvertently relying on undocumented behavior that happens to work on FC2 (my primary development system) but not on SuSE 9.1.

I can provide more sample code, but for starters here's my video and keyboard init code:

initscr ();
if (debug)
   immedok (stdscr, TRUE);
start_color ();
if (debug)
   cbreak ();
else
   raw ();
noecho ();
nonl ();
keypad (stdscr, TRUE);
intrflush (stdscr, FALSE);
meta (stdscr, TRUE);

When I use my own SIGWINCH handler, I issue halfdelay (10) before wgetch (stdscr) which allows my SIGWINCH handler to handle the resize and ungetch (KEY_RESIZE) before my wgetch wrapper function returns to its caller.

Any thoughts on how I might make my app exhibit consistent window resizing behavior on these two distros?

Thanks,
Dave
--
Dave Ulrick
Email: address@hidden
Web:   http://www.niu.edu/~ulrick/




reply via email to

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