Mail Archives: cygwin/2014/05/14/14:01:08
H,
On 2014-05-15 02:46+0100, Andrew Schulman wrote:
<snip/>
>> 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.
>>
<snip/>
> 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
- Raw text -