From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4801 invoked by alias); 14 May 2014 18:00:50 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 4785 invoked by uid 89); 14 May 2014 18:00:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: mail6.worldispnetwork.com Received: from Unknown (HELO mail6.worldispnetwork.com) (74.50.84.133) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 14 May 2014 18:00:47 +0000 Received: (qmail 5552 invoked by uid 399); 14 May 2014 18:00:46 -0000 Received: from unknown (HELO ?0.0.0.0?) (career@shaddybaddah.name@121.211.112.145) by mail6.worldispnetwork.com with ESMTPAM; 14 May 2014 18:00:46 -0000 Message-ID: <5373AF2E.5090402@shaddybaddah.name> Date: Wed, 14 May 2014 18:16:00 -0000 From: Shaddy Baddah User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: screen on 64-bit mangles mintty/buffer References: <5370E144.4010905@shaddybaddah.name> <90t1n9l4g51dgrq060rc6ua48eog4178v8@4ax.com> In-Reply-To: <90t1n9l4g51dgrq060rc6ua48eog4178v8@4ax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00318.txt.bz2 H, On 2014-05-15 02:46+0100, Andrew Schulman wrote: >> The problem only occurs with screen on 64-bit Cygwin. The 32-bit appears >> to work correctly. The problem is that when screen is run in mintty, it >> seems to exclude the bottom line, reducing the actual size of the >> buffer. Further, something goes awry at the top. So that if you run >> emacs -nw or less from within, scrolling via the keys acts very >> strangely. >> >> If you detach or simply exit the screen session, the problem carries on >> on the mintty you are left with. >> > OK. This sounds like the same problem as: > > http://cygwin.com/ml/cygwin/2014-01/msg00223.html > > Actually that report is sort of the opposite problem: all of the > scrolling is down in the bottom line. But it sure sounds like the same > thing. > > The details of what people report vary. For me, scrolling ends up all > down in the bottom line, and resizing the window doesn't fix it. > > I also see the problem only in 64-bit. It works fine in 32-bit. > > I have found one reliable workaround, at least for me: The problem only > happens if I start screen from my .bash_profile. If I start it from the > command line, it works fine. I don't know yet why that is, but it's a > clue. Probably an environment difference. > > Are you using the latest screen release, 4.2.1? Please send output of > cygcheck -svr. > >> My foolishness in not reporting this as soon as I detected it is that >> my attempts to bisect/rollback to a period where my recollection >> suggests the problem did not exist, have not succeeded. In other words, >> my tests indicate this has been around since screen was built and >> released for 64-bit Cygwin. >> >> I was hoping to understand the terminal handling and suggest a fix, but >> it is a little bit beyond my capability at the moment. Any help would >> be appreciated (I usually quarantine one mintty which I use for managing >> a handful of screen sessions to work around the problem). > > No problem, thanks for reporting. Corinna suggests that it's a mintty > problem. Is that more likely than a screen problem? I don't know. If > it is a screen problem, I don't have the skills to offer a fix - all I > can do is report it to the screen-users list. OK, after much debugging, I have got somewhere. Although my understanding is not 100% complete at this point, but I need to stop for a bit. There seems to me to be a number of small problems that have chained themselves into a larger complex problem. Comparing the control sequence output of the 64-bit against the 32-bit build of screen, I quickly noticed that the problem was that 64-bit screen was incorrectly parameterizing the output for the CS (clear screen) capability (on a 40 line sized mintty): 64-bit: "\e[0;39r" 32-bit: "\e[1;40r" This means that the screen session itself if incorrectly ignoring the last visible line (equivalent of a viewport shifted up a line), on both putty and mintty. Unfortunately, the incorrect parameters reek havoc on mintty, but not on putty. Once the original buffer is returned (as opposed to screens alternate buffer), putty is ok. mintty could handle this better, but it is not the root cause of the issue. Seeing that on 64-bit, the control sequence was being generated by tgoto (/tparm) as per: screen-4.2.1/display.c:2869: debug2("ChangeScrollRegion: (%d - %d)\n", newtop, newbot); screen-4.2.1/display.c:2870: AddCStr(tgoto(D_CS, newbot, newtop)); I found the termcap/info def for cs to be "\e[%i%d;%dr". The %i indicates that both parameters (%d) should be incremented by 1. This was not occurring. So I went about debugging libncursesw10 to understand why. I worked out that tgoto() was calling tparam(). And tparam() was set to be tparam_internal(), within lib_tparm.c. I quickly worked out that the code has a bug for "%i". At some point the code was changed to push and pop the parameters being passed (0 and 39 in my eg.). However, the "%i" select/case block was incrementing the arguments in a no longer used array for parameters: case 'i': if (p_is_s[0] == 0) param[0]++; if (p_is_s[1] == 0) param[1]++; break; only the stack was being used to substitute the "%d"'s. Not understanding why it was OK on the 32-bit build, I started debugging it. Amongst the first problems I noticed is... the screen-4.2.1-1 package is linked against libncurses10-5.7-18, whereas my build was linking against libncursesw10-5.7-18. Not a major deal, everything seems to be interchanging (ie. screen 32-bit is working regardless of either). Looking into the code for this slight older version (that 64-bits libncursesw10-5.9-4), I noticed that the questionable code exists there too. Looking elsewhere for a difference, I noted that the 32-bit screen was parameterizing a different definition for cs, "\e[%i%p1%d;%p2%dr". Notice the "%p." notation. I've come to understand now that the two notations differ in that the 64-bit is using the termcap style, and the 32-bit is using terminfo style definition (at least that's what I think I understand). The latter style bypasses what is in my view the broken code. Trying to understand why screen ends up choosing one definition over the other, I have come to realise it all stems from the config.h generated by configure across the two platforms. The 32-bit defines TERMINFO: config.h: /* * Define TERMINFO if your machine emulates the termcap routines * with the terminfo database. * Thus the .screenrc file is parsed for * the command 'terminfo' and not 'termcap'. */ #define TERMINFO 1 configure.log: configure:5025: $? = 0 configure:5025: ./conftest.exe configure:5025: $? = 1 configure: program exited with status 1 configure: if ac_fn_c_try_run "$LINENO"; then : echo "- you use the termcap database" 1>&6 else echo "- you use the terminfo database" 1>&6 $as_echo "#define TERMINFO 1" >>confdefs.h fi the 64-bit does not: /* #undef TERMINFO */ configure:5025: $? = 0 configure:5025: ./conftest.exe configure:5025: $? = 0 I can't understand why the ./conftest.exe differ. Trying to emulate by hand, I cannot reproduce it. But it is now very late here, and I can't debug anymore. I'm hoping that I've provided enough of a lead for someone of authority to decide where things are right, and where things are wrong. -- Thanks, Shaddy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple