>Path: news.tetherless.net!news.zeitgeist.net!news.sprintlink.net!howland.reston.ans.net!vixen.cso.uiuc.edu!gateway
>From: jmc@sisko.co.uk
>Newsgroups: info.bsdi.users
>Subject: Bug in debug code in curses library.
>Date: 12 Apr 95 10:52:00 GMT
>Organization: University of Illinois at Urbana
>Lines: 88
>Approved: Usenet@ux1.cso.uiuc.edu
>Message-ID: <9504121152.AA00558@sisko.co.uk>
>NNTP-Posting-Host: ux1.cso.uiuc.edu
>Content-Type: text
>Originator: daemon@ux1.cso.uiuc.edu
>


I have been (successfully) trying to find out the cause of bug with multiple
overlapping windows in "libcurses".

In case you don't know what I'm talking about, try compiling the
following program on various systems.

System V systems leave a blank screen.

BSDI, AIX, SunOS (etc etc) systems display the line.

I think that the screen should be blank.

I use this sort of thing to generate "popups" and try to repair the
screen afterwards (yes I have heard of X-windows but then
unfortunately those nasty custs haven't), and I keep finding bits of
the "popped-up" window splattered all over the original window.

=======Demo program==== SNIP SNIP SNIP =====================================

#include <curses.h>
main()
{
	WINDOW	*w1, *w2;
	initscr();
	w1 = newwin(10, 0, LINES-10, 0);
	w2 = newwin(10, 0, LINES-10, 0);
	mvwaddstr(w1, 8, 0, "BUG PRESENT IF THIS LINE IS ON THE SCREEN!!!!!!!");
	wrefresh(w1);
	wrefresh(w2);
	endwin();
	return  0;
}

=======End of Demo program==================================================


Compiling the curses library with -DDEBUG I find that I get a core
dump when I try to run the above demo program. This is because the
debug tracing code in "refresh.c" assumes that the number of lines in
"win" == the number in "curscr".

I have a suspicious feeling that this code has been something like
this from the dawn of time.....

As for the bug itself, it turns out that the logic for deciding what
is "dirty" is broken. It just takes ranges of lines and columns within
lines which have been touched in the subwindow and in refresh.c
updates curscr just in that area, even though the previous contents of
curscr on either side might not have come from the subwindow.
Even worse, it sets the "hash" value for each line to be that for the
subwindow so that it perpetuates the error for some time until the
relevant curscr line is properly updated.

Here is a patch to the debug code in case anyone is interested. I
haven't fixed the main problem as that won't help with the other
systems I've mentioned.

The workaround for the main problem seems to be to insert
"touchwin(w2);" immediately before the "wrefresh(w2);". 

Again this must be a "dawn of time" problem. I see that System V
curses WINDOW structures don't have the "firstch" and "lastch"
pointers in so that logic must have been abandoned altogether.


*** refresh.c.orig	Wed Apr 12 10:33:42 1995
--- refresh.c	Wed Apr 12 08:21:26 1995
***************
*** 130,135 ****
--- 130,139 ----
  			           curscr->lines[i]->line[j].attr);
  			__CTRACE("\n");
  			__CTRACE("W: %d:", i);
+ 			if  (i >= win->maxy) {
+ 				__CTRACE("W:EOW\n");
+ 				continue;
+ 			}
  			__CTRACE(" 0x%x \n", win->lines[i]->hash);
  			__CTRACE(" 0x%x ", win->lines[i]->flags);
  			for (j = 0; j < win->maxx; j++)

-- 
John M Collins		Xi Software Ltd,  email: jmc@xisl.co.uk
Snail mail:	  6 West Burrowfield, Welwyn Garden City, Herts, AL7 4TW
Office Phone/Fax: 	+44 1707 371405/335801
Home Phone/Car Phone:	+44 1727 857267/836 716640