From: Sous Lesquels <a9f54d2@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Some programs (vi, ssh) crash when screen buffer height is big
Date: Thu, 20 Aug 2015 22:21:00 -0000 [thread overview]
Message-ID: <CAHV8iDGU8tN+58LR10e3zHxiEsr5ekXrKrLeyYRAD0tx0H6B1A@mail.gmail.com> (raw)
In-Reply-To: <26A19798-1F20-4D52-A311-C8312E0D4621@etr-usa.com>
Thanks Warren.
> Actually, it did here.
I see it separate, at least in a Web browser:
- This thread: https://cygwin.com/ml/cygwin/2015-08/threads.html#00347
- The original thread I tried to reply to:
https://cygwin.com/ml/cygwin/2014-07/threads.html#00185
My intention was to reply to this message:
https://cygwin.com/ml/cygwin/2014-07/msg00191.html
> You are aware that Microsoft is giving out free Windows 10 upgrades to valid Windows 7 license holders, right?
Yeah - however, wanted to test under relatively same conditions
considering what I use daily and I don't decide when to get the
upgrade here...
> but also because I continue to be unable to reproduce your symptom under Windows 10
Just to confirm - you did set the params of cmd.exe one to this:
Screen Buffer Size: 208w 9999h
Window Size: 208w 69h
the files you headed have long lines and you are using 64bit Cygwin?
Those two seem really important. I did not have issues with 32bit. I
seem not to have issues with smaller windows / buffer sizes. I also
don't seem to be able to reproduce when files have short lines.
> I’ve also failed to reproduce your symptom under MinTTY
I cannot reproduce under mintty either.
> (You can make the test script time(1)-able by adding “-c q” to the vim command, so that it immediately quits after loading the log file.)
Nah, not needed that much - it crashes itself most of the time :)
> When you say “completely fresh…Cygwin”, do you mean that you didn’t even start with an archive of downloaded packages?
Yep - I basically had a fresh Win 7 and used internet to download all things.
> Did you use a different package mirror?
Yes - I can try with the same mirror if you think that would make a
difference. Given that I am constantly (as in - 20 times a day at
least) reproducing this on three different machines, different
versions of Cygwin (I likely updated it a few times since last year),
etc., I would say that's not very likely a cause.
> I don’t know if this is relevant, but have you done a memtest86 (or similar) pass on that machine? Dodgy RAM could explain intermittent calloc() failures.
It's actually two different machines. One is physical and one a VM on
a totally different physical machine. I also tried it on a third VM
(which is on a third physical machine). It should not be machine
related.
Note that I get a lot of different behaviors, here are some:
- cmalloc would have returned NULL that you referenced
- Garbage on screen - e.g. my PS1 has some ANSI color escape codes and
they look not to be interpreted when it goes into this state. I have:
PS1=\[\e[31m\]
and instead of making text red, it actually prints
[31m
- Mixed text - e.g. I scroll a line in vim (but happens also with
less, cat, etc.) and it doesn't clear the screen completely, i.e.
mixes old and new contents
- Segfaults
It's very interesting that only I can reproduce. Cannot pinpoint what
can be the difference between the envs... :(
--
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
next prev parent reply other threads:[~2015-08-20 22:21 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-20 16:35 Sous Lesquels
2015-08-20 21:45 ` Warren Young
2015-08-20 22:21 ` Sous Lesquels [this message]
2015-08-20 22:36 ` Warren Young
2015-08-21 12:37 ` Sous Lesquels
2015-08-21 18:53 ` Warren Young
2015-08-21 21:41 ` Thomas Wolff
2015-08-24 12:08 ` Philip Daniels
2015-08-25 16:35 ` Sous Lesquels
2015-08-25 16:47 ` cyg Simple
2015-08-27 19:47 ` Sous Lesquels
2015-08-28 13:23 ` Larry Hall (Cygwin)
2015-08-28 14:05 ` Sous Lesquels
2015-08-28 18:50 ` Larry Hall (Cygwin)
2015-08-28 21:31 ` Sous Lesquels
2015-08-28 21:53 ` Warren Young
2015-08-28 23:24 ` Warren Young
2015-08-25 18:20 ` Andrey Repin
2015-08-27 20:00 ` Sous Lesquels
2015-08-28 14:48 ` Andrey Repin
2015-08-28 21:09 ` Sous Lesquels
2015-08-28 23:27 ` Andrey Repin
2015-08-20 22:35 ` Andrey Repin
-- strict thread matches above, loose matches on Subject: below --
2014-07-16 20:10 sous lesquels
2014-07-16 20:30 ` sous lesquels
2014-07-17 2:13 ` Christopher Faylor
2014-07-17 8:24 ` Corinna Vinschen
2014-07-18 3:28 ` Warren Young
2014-07-18 14:48 ` sous lesquels
2014-07-18 15:51 ` Larry Hall (Cygwin)
2014-07-18 16:59 ` sous lesquels
2014-07-18 17:59 ` Christopher Faylor
2014-07-18 18:48 ` Nellis, Kenneth
2014-07-18 20:35 ` sous lesquels
2014-07-21 12:32 ` Nellis, Kenneth
2014-07-23 0:50 ` Christopher Faylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHV8iDGU8tN+58LR10e3zHxiEsr5ekXrKrLeyYRAD0tx0H6B1A@mail.gmail.com \
--to=a9f54d2@gmail.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).