Re: Some programs (vi, ssh) crash when screen buffer height is big

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Sous Lesquels]

--- Prelude

I don't think this message will thread correctly. This is a reply to
this message:

https://cygwin.com/ml/cygwin/2014-07/msg00191.html

Message-ID: <20140717082423.GB15332@calimero.vinschen.de>

I unsubscribed from the list in order not to get emails for the whole
list (most of which I'm not interested in, as I'm a Cygwin user
primarily, not a developer), so I don't have the original message to
reply to. Gmail doesn't allow setting In-Reply-To or References
header. I tried what was suggested here:

https://cygwin.com/ml/cygwin/2014-07/msg00222.html

but this replied to cygwin-help@cygwin.com and was auto-bounced. If
anyone has ideas how to thread this properly using clients that do not
support adding user headers (Gmail Web interface for example), without
having the original message to reply to, let me know, so I use that in
the future.

--- The actual message

Thanks Corinna. I initially thought this was an installation issue
and, after this continued to happen and nobody else could reproduce, I
conceded to what you suggested, it's possibly a BLODA thing.

However, just had a completely fresh Win7 and Cygwin install, with
these versions:

cygwin               2.2.1-1            OK
vim                  7.4.808-1          OK

CYGWIN_NT-6.1 2.2.1(0.289/5/3) 2015-08-20 11:42 x86_64 Cygwin

Aside from a few apps (such as Chrome, but nothing "invasive" such as
antivirus or so), it does not have anything that a regular Win7
machine would not have, so I don't think BLODA can be considered as a
cause here.

I tested it by running the script I provided before, i.e.:

#!/bin/bash
for i in {1..123}; do
  echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
  head -n1000 /var/log/setup.log
done
vi /var/log/setup.log

I can reproduce it often. Not always, but I would say if you cannot
reproduce it with the above script and the below details 1 in 3 times,
I would be very surprised.

From my limited testing:

- It's imperative that the buffer size is big - 9999 is the best
choice - and also the window size. I have mine with Screen Buffer Size
208w 9999h and Window Size 208w 69h, font Lucida Console 14pt
- I could not reproduce in Cygwin terminal (i.e. mintty, as per the
desktop shortcut Cygwin creates), only in cmd (which is the default
when running Cygwin.bat) and ConEmu
(https://github.com/Maximus5/ConEmu)
- The behavior seems different in cmd and ConEmu. When in plain cmd,
cmd crashes and leaves vim process in behind using one core. ConEmu
kills both
- It looks like the file being head-ed above (/var/log/setup.log in my
example) needs to have long lines. Using a big binary dll file
(something from c:/windows/system32) doesn't seem to cause it

Since, when started from cmd, vim continues to run, I did a strace on
vi and pasted it partially here (sorry, cannot post all), hope I did
not miss anything that's important.

http://pastie.org/10364022

Looks like it goes into some loop (the last part of strace just loops
over and over).

Cmd (or bash?) itself crashes with the usual dialog that windows shows
when the app crashes - the text is the usual "Console Window Host has
stopped working". No coredump is produced.

If you need me to test anything else or more information, let me know,
if not sensitive I should be able to provide.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Warren Young]

On Aug 20, 2015, at 10:34 AM, Sous Lesquels <a9f54d2@gmail.com> wrote:
> 
> I don't think this message will thread correctly.

Actually, it did here.

> However, just had a completely fresh Win7 and Cygwin install

You are aware that Microsoft is giving out free Windows 10 upgrades to valid Windows 7 license holders, right?

    http://www.microsoft.com/en-us/windows/windows-10-upgrade

I bring it up not just because it’s the new shiny, but also because I continue to be unable to reproduce your symptom under Windows 10, and Microsoft did a huge amount of work on the Windows console in this release:

    https://goo.gl/t9KXpC

I’ve also failed to reproduce your symptom under MinTTY, though you may be interested to know that the test cycle completes in about 1/12 the time here. :)  (Over 2 min for cmd.exe vs about 10 sec for MinTTY.)

(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.)

I did 5+ test runs under each console.

When you say “completely fresh…Cygwin”, do you mean that you didn’t even start with an archive of downloaded packages?  Did you use a different package mirror?

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.
--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Sous Lesquels]

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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Andrey Repin]

Greetings, Warren Young!

> On Aug 20, 2015, at 10:34 AM, Sous Lesquels <a9f54d2@gmail.com> wrote:
>> 
>> I don't think this message will thread correctly.

> Actually, it did here.

>> However, just had a completely fresh Win7 and Cygwin install

> You are aware that Microsoft is giving out free Windows 10 upgrades to
> valid Windows 7 license holders, right?

And you did read the Win10 EULA, right?

>     http://www.microsoft.com/en-us/windows/windows-10-upgrade

> I bring it up not just because it’s the new shiny, but also because I
> continue to be unable to reproduce your symptom under Windows 10, and
> Microsoft did a huge amount of work on the Windows console in this release:

>     https://goo.gl/t9KXpC

That doesn't help people who don't want to install spying OS on their
computers.
And that's just one of the reasons people don't want to deal with it.

> I’ve also failed to reproduce your symptom under MinTTY, though you may be
> interested to know that the test cycle completes in about 1/12 the time
> here. :)  (Over 2 min for cmd.exe vs about 10 sec for MinTTY.)

> (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.)

> I did 5+ test runs under each console.

> When you say “completely fresh…Cygwin”, do you mean that you didn’t even
> start with an archive of downloaded packages?  Did you use a different package mirror?

> 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.


-- 
With best regards,
Andrey Repin
Friday, August 21, 2015 01:29:23

Sorry for my terrible english...

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Warren Young]

On Aug 20, 2015, at 4:21 PM, Sous Lesquels <a9f54d2@gmail.com> wrote:
>> 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

Oh, I’ve been assuming that it was the *length* that matters.  I’m an old-skool kinda guy, so I’ve been keeping it to 80 columns.

After sending the window full-screen, lookee lookee:

2014/11/04 17:40:58 Ending cygwin install
    112 [main] vi 4424 C:\cygwin64\bin\vi.exe: *** fatal error - cmalloc would have returned NULL
/x: line 6:  4424 Hangup                  vi -c q /var/log/setup.log

It happened on the first run, with a 317x85 window and 9999 lines of scrollback buffer.

>> Did you use a different package mirror?
> 
> Yes - I can try with the same mirror if you think that would make a
> difference.

Actually, you did the test I wanted: you proved that a different mirror gives the same results, which rules out bad packages on one rogue mirror.  The chance of two bad mirrors is exceedingly tiny, so we can assume the packages are fine, unless they’re corrupt on sourceware, which is also unlikely.

>> I’ve also failed to reproduce your symptom under MinTTY
> 
> I cannot reproduce under mintty either.

So why not run under mintty, then?  Cygwin runs better under mintty in general.
--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Sous Lesquels]

Thanks Warren.

> After sending the window full-screen, lookee lookee:
>
> 2014/11/04 17:40:58 Ending cygwin install
>    112 [main] vi 4424 C:\cygwin64\bin\vi.exe: *** fatal error - cmalloc would have returned NULL
> /x: line 6:  4424 Hangup                  vi -c q /var/log/setup.log
>
> It happened on the first run, with a 317x85 window and 9999 lines of scrollback buffer.

OK, at least it's reproducible by one more person :)

> So why not run under mintty, then?  Cygwin runs better under mintty in general.

For various usability reasons (tabs being the biggest I think), I'm
using ConEmu (https://github.com/Maximus5/ConEmu) and running bash
directly from it. I am not sure if it's even possible to use mintty -
it just might run console -> mintty -> bash, so might present the same
issue - but will take a look at that to confirm.

However, assuming it is not possible to run mintty under ConEmu and
short of downsizing the window, do you know of any solutions /
workarounds I have with the default console that I can try?

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Warren Young]

On Aug 21, 2015, at 6:37 AM, Sous Lesquels <a9f54d2@gmail.com> wrote:
> 
>> It happened on the first run, with a 317x85 window and 9999 lines of scrollback buffer.
> 
> OK, at least it's reproducible by one more person :)

A replicable bug is a dead bug.  All that’s needed is for someone to spend the time to chase it down.

My interest stopped with replicating the bug.  I have no skin in the game beyond that.  I don’t use anything but mintty these days, except when forced, and don’t use Cygwin or Windows enough to miss tabs when I can’t use an OS where the native terminal emulator has them.

> For various usability reasons (tabs being the biggest I think), I'm
> using ConEmu

Perhaps SuperPutty would work for you:

  https://github.com/jimradford/superputty

It claims to run putty as a subprocess, providing tabs and scp support on top of it.  Since mintty is a fork of putty, it might be a drop-in replacement, or an easy hack if not.

It appears to be written in C#, so I doubt it would be allowed to incorporate this code into mintty itself, though.


--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Thomas Wolff]

Am 21.08.2015 um 14:37 schrieb Sous Lesquels:
> However, assuming it is not possible to run mintty under ConEmu ...
It is.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Philip Daniels]

> For various usability reasons (tabs being the biggest I think), I'm
> using ConEmu (https://github.com/Maximus5/ConEmu) and running bash
> directly from it. I am not sure if it's even possible to use mintty -
> it just might run console -> mintty -> bash, so might present the same
> issue - but will take a look at that to confirm.

> However, assuming it is not possible to run mintty under ConEmu and
> short of downsizing the window, do you know of any solutions /
> workarounds I have with the default console that I can try?

It *is* possible to run mintty under ConEmu. However, ConEmu is designed
as a wrapper around the windows console and doesn't understand Unix-style
terminals such as mintty. Therefore it runs mintty as a "graphical process",
basically reparenting its window. (You can run MS Paint in ConEmu in the
same way...). It works reasonably well, but recent builds of ConEmu exhibit
a problem with focus, moving between mintty instances with the keyboard
or mouse doesn't always move typing focus, which kinda undermines the
multi-tab approach. The problem occurs somewhere after ConEmu build
140109.

I have not tested it with the latest mintty or ConEmu though, so maybe
that problem has gone away? If you test it let us know.

As an example, this task will start 2 minttys in one tab, horizontally
split, using a theme file I have under my home directory and using
the Cygwin icon. CYGROOT is typically C:\Cygwin, of course. Note that
you need the leading ">", it is not part of email quotation!


> %CYGROOT%\bin\mintty.exe -c %USERPROFILE%\repos\dotfiles\colors\mintty-themes\SolarizedDark - -new_console:n:C:%CYGROOT%\Cygwin.ico

%CYGROOT%\bin\mintty.exe -c
%USERPROFILE%\repos\dotfiles\colors\mintty-themes\SolarizedDark -
-cur_console:s1THn:C:%CYGROOT%\Cygwin.ico


Because of the focus problems I am using ConEmu less now, I tend
to use tmux (though alas, that brings in its own separate problems due
to differing terminal emulations meaning some of my Emacs keybindings
don't work, grrrr).


On 21 August 2015 at 13:37, Sous Lesquels <a9f54d2@gmail.com> wrote:
> Thanks Warren.
>
>> After sending the window full-screen, lookee lookee:
>>
>> 2014/11/04 17:40:58 Ending cygwin install
>>    112 [main] vi 4424 C:\cygwin64\bin\vi.exe: *** fatal error - cmalloc would have returned NULL
>> /x: line 6:  4424 Hangup                  vi -c q /var/log/setup.log
>>
>> It happened on the first run, with a 317x85 window and 9999 lines of scrollback buffer.
>
> OK, at least it's reproducible by one more person :)
>
>> So why not run under mintty, then?  Cygwin runs better under mintty in general.
>
> For various usability reasons (tabs being the biggest I think), I'm
> using ConEmu (https://github.com/Maximus5/ConEmu) and running bash
> directly from it. I am not sure if it's even possible to use mintty -
> it just might run console -> mintty -> bash, so might present the same
> issue - but will take a look at that to confirm.
>
> However, assuming it is not possible to run mintty under ConEmu and
> short of downsizing the window, do you know of any solutions /
> workarounds I have with the default console that I can try?
>
> --
> 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
>



-- 
Philip Daniels.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Sous Lesquels]

Thanks Philip - I agree with that and it's even nicely described in ConEmu docs:

http://conemu.github.io/en/CygwinAnsi.html

While it might be a hack to get this working, mintty is not something
that should be run in ConEmu, as both are terminal emulators.

Anyway, I guess the question is - is Cygwin supposed (as in - designed
with that in mind) to be working only under mintty or is it supposed
to work with regular Windows console? Trying to figure out what to do
- if it's not supposed to work outside of mintty, that cuts down the
options considerably.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[cyg Simple]

On 8/25/2015 12:35 PM, Sous Lesquels wrote:
> Thanks Philip - I agree with that and it's even nicely described in ConEmu docs:
> 
> http://conemu.github.io/en/CygwinAnsi.html
> 
> While it might be a hack to get this working, mintty is not something
> that should be run in ConEmu, as both are terminal emulators.
> 
> Anyway, I guess the question is - is Cygwin supposed (as in - designed
> with that in mind) to be working only under mintty or is it supposed
> to work with regular Windows console? Trying to figure out what to do
> - if it's not supposed to work outside of mintty, that cuts down the
> options considerably.

It depends on the level of support you want from this list.  If you have
issues with executing something or you have issues with visual and
keyboard function the answer is always to use mintty.  That is what the
installer sets up for you and is expected that you are using. Otherwise
you may be on your own to determine the issue but we try to be a helpful
lot.

-- 
cyg Simple

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Andrey Repin]

Greetings, Sous Lesquels!

> Thanks Philip - I agree with that and it's even nicely described in ConEmu docs:

> http://conemu.github.io/en/CygwinAnsi.html

> While it might be a hack to get this working, mintty is not something
> that should be run in ConEmu, as both are terminal emulators.

> Anyway, I guess the question is - is Cygwin supposed (as in - designed
> with that in mind) to be working only under mintty or is it supposed
> to work with regular Windows console?

You're misunderstanding Cygwin, if you are asking such questions.

> Trying to figure out what to do - if it's not supposed to work outside of
> mintty, that cuts down the options considerably.

Cygwin is designed to work. Native console or mintty - they are just terminals
that are in parallel to the nature of Cygwin as a platform for portable
software.
It comes by no surprize, that certain terminals have limitations, and indeed
Cygwin terminal driver for native console have more issues than most due to
the nature of native console.
mintty was born exactly to combat the deficiencies of native console.
It understand and provide all the normal TTY functionality a POSIX application
expects, it even fix some deviations of PuTTY code it is based upon, making it
a preferred choice for remote terminals.
If you could convince ConEmu developers to provide adequate TTY functionality,
you can just use it as a replacement for mintty, instead of trying to nest
terminal emulators, which would never work straight.


-- 
With best regards,
Andrey Repin
Tuesday, August 25, 2015 21:03:24

Sorry for my terrible english...


--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Sous Lesquels]

Thanks cyg Simple.

> It depends on the level of support you want from this list

In this case, if Cygwin is supposed to work with the regular windows
console? If mintty was created due to Cygwin *not working as expected*
on default windows console, that's a good answer, as long as it's
correct. If Cygwin *should* work on default windows console, then I
would appreciate someone explaining if there's a workaround, if this
would be considered a candidate for development any time soon, things
like that.

I don't expect anything. I'm not paying others to develop. I do hope
the bugs are fixed, one way or another, as I use Cywgin daily, so of
course I'd like it to work in an environment I have and like.

> That is what the installer sets up for you and is expected that you are using.

Installer also sets up Cygwin.bat in the home folder. Run it, run my
tests exactly as described in my previous posts, it will yield in a
break.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Sous Lesquels]

Thanks Andrey.

> You're misunderstanding Cygwin, if you are asking such questions.

Care to clarify how am I misunderstanding Cygwin?

> If you could convince ConEmu developers to provide adequate TTY functionality,

You mean Microsoft? You can reproduce the exact same issue with the
native windows console. Run Cygwin.bat from the home folder, run my
tests exactly as described in my previous posts, it will break.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Larry Hall (Cygwin)]

On 08/27/2015 11:39 AM, Sous Lesquels wrote:
> Thanks cyg Simple.
>
>> It depends on the level of support you want from this list
>
> In this case, if Cygwin is supposed to work with the regular windows
> console? If mintty was created due to Cygwin *not working as expected*
> on default windows console, that's a good answer, as long as it's
> correct. If Cygwin *should* work on default windows console, then I
> would appreciate someone explaining if there's a workaround, if this
> would be considered a candidate for development any time soon, things
> like that.
>
> I don't expect anything. I'm not paying others to develop. I do hope
> the bugs are fixed, one way or another, as I use Cywgin daily, so of
> course I'd like it to work in an environment I have and like.

I think you're misunderstanding where the limitation is coming from.
The console itself is limited in functionality compared to what's
expected of a terminal.  Cygwin can only do so much to smooth out
those limitations.  This particular issue is a corner case, perhaps
an extreme corner case.  If there is some work-around that could be
found and/or implemented, it's probably of limited value in general
so it's likely that someone with the itch will need to chase
this down and implement a workaround if possible.  Besides that, the
alternatives are to side-step the console limitations by using mintty
or take this upstream to ComEmu or MS.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Sous Lesquels]

Thanks Larry.

> I think you're misunderstanding where the limitation is coming from.

I don't think I'm misunderstanding anything - I was actually thinking
along the same lines that you just wrote.

I feel that with increasing monitors sizes == increasing window sizes,
it might happen more often, as not all people use mintty. I can change
from ConEmu to mintty, but IMHO that's like saying I can use the
stairs instead of an elevator in Burj Khalifa. I don't and cannot
expect anything from Cygwin team, which is providing something I like
and use every day. If there are more important problems that mine
never comes to the top, then that's what it is.

I still hope someone will be able to check. It looks to me this might
be one of those "640k will be enough" problems, with some buffer with
fixed size that nobody anticipated will not be "big enough". Or it
might be something completely different. Even if it's just me that's
affected, I understandably would like that to stop happening. If it
does, I'd be so much happier. If it doesn't, tough luck. I've been
dealing with several dozen restarts each day for at least a year when
I first reported the problem, but I still like it and use it.

Saying "it's ms bug", "it's a design choice", "it's a bug, but we
don't have time / resources to fix it", "it happens so rarely, we
don't care", "it's going to be fixed in 2030", etc. is fine with me.
It might mean that I should not expect this to work any time soon or
ever, but it would be a honest answer and, if coming from someone on
the team itself, hopefully correct. Instead, a few different people
replied to me on this thread with "you misunderstanding, ignorant
quack".

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Andrey Repin]

Greetings, Sous Lesquels!

> Thanks Andrey.

>> You're misunderstanding Cygwin, if you are asking such questions.

> Care to clarify how am I misunderstanding Cygwin?

I'm not in the mood of retyping the POSIX standard for you.

>> If you could convince ConEmu developers to provide adequate TTY functionality,

> You mean Microsoft?

I'm personally acquainted with the creator of ConEmu and he's not working for
Microsoft.

> You can reproduce the exact same issue with the native windows console.

Yet again, Cygwin tools themselves and terminal you use them in is two
perpendicular things.

> Run Cygwin.bat from the home folder, run my
> tests exactly as described in my previous posts, it will break.

You know, what I can say about it?

- Doctor, when I twist my finger this way, it hurts!
- Don't twist your finger this way.

ConEmu, same as mintty, was created to fight deficiency of the native console.
If, having better alternative, you still cling to the native console, you're
the sole responsibility of all that happens to you.


-- 
With best regards,
Andrey Repin
Friday, August 28, 2015 17:11:49

Sorry for my terrible english...


--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Larry Hall (Cygwin)]

On 08/28/2015 09:23 AM, Sous Lesquels wrote:
> Thanks Larry.
>
>> I think you're misunderstanding where the limitation is coming from.
>
> I don't think I'm misunderstanding anything - I was actually thinking
> along the same lines that you just wrote.

OK, good. We're on the same page then.  :-)

> I feel that with increasing monitors sizes == increasing window sizes,
> it might happen more often, as not all people use mintty. I can change
> from ConEmu to mintty, but IMHO that's like saying I can use the
> stairs instead of an elevator in Burj Khalifa. I don't and cannot
> expect anything from Cygwin team, which is providing something I like
> and use every day. If there are more important problems that mine
> never comes to the top, then that's what it is.

Well, if there is a change in ConEmu and/or MS support here, then it
all comes for free. ;-)  As I said, I'm not saying that there's
absolutely nothing that could be done to address this in Cygwin but I'm
also not saying that there is.  It is clearly a limitation that currently
has no known work-around for the specific issue without avoiding the MS
console.

> I still hope someone will be able to check. It looks to me this might
> be one of those "640k will be enough" problems, with some buffer with
> fixed size that nobody anticipated will not be "big enough". Or it
> might be something completely different. Even if it's just me that's
> affected, I understandably would like that to stop happening. If it
> does, I'd be so much happier. If it doesn't, tough luck. I've been
> dealing with several dozen restarts each day for at least a year when
> I first reported the problem, but I still like it and use it.

Yeah, I understand the frustration and it's certainly not wrong of
you to report the problem you're seeing.  And be assured that your
report isn't ignored.  But it is something that may be difficult to
address in Cygwin's console support so  it's hard to say there's going
to be a good solution coming from Cygwin itself soon, unless there's
some developer that wants to chase this in the near-term.

> Saying "it's ms bug", "it's a design choice", "it's a bug, but we
> don't have time / resources to fix it", "it happens so rarely, we
> don't care", "it's going to be fixed in 2030", etc. is fine with me.
> It might mean that I should not expect this to work any time soon or
> ever, but it would be a honest answer and, if coming from someone on
> the team itself, hopefully correct. Instead, a few different people
> replied to me on this thread with "you misunderstanding, ignorant
> quack".

I'm pretty sure that no-one actually meant to imply that you're an
"ignorant quack".  I can also say that Cygwin does support the MS
console to the extent that the MS console API allows.  That's not to
say there aren't bugs in that support or that any bugs aren't considered.
It seems you've found such a bug so I will thank you for reporting it.
And while I can't speak for any of the developers on this list, I only
wanted to impart that this issue is likely to be viewed as relatively
low priority, given the specifics of the issue and the alternatives.
You shouldn't interpret my response as one that indicates that the bug
won't be addressed or that your report isn't appreciated.  My only goal
was to try to give you the feedback you were looking for.  With some
luck, someone will find the solution to this problem even if they aren't
really looking for it and, you never know, that could happen real soon!
So I hope you find this feedback to be helpful in answering some of your
inquiries.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Sous Lesquels]

> I'm not in the mood of retyping the POSIX standard for you.

But you are obviously always in the mood to be unhelpful...

> I'm personally acquainted with the creator of ConEmu and he's not working for Microsoft.

And this breaks without ConEmu. If you forget I said that I use ConEmu
and run my example in a native Microsoft-made console, it will break.
So please clarify to me how this has to do with ConEmu?

> Yet again, Cygwin tools themselves and terminal you use them in is two perpendicular things.

So are Cygwin tools and airplanes. Or Cygwin tools and stick figures.
What's your point?

> You know, what I can say about it?
>
> - Doctor, when I twist my finger this way, it hurts!
> - Don't twist your finger this way.

If you took a few minutes to think, you'd understand that in this case
I have two choices - use mintty and have no breaks or use ConEmu and
have breaks. The continuation of your imaginary dialogue above would
be:

- But doctor, it hurts any way I move my finger!

What would the doctor say, stop using your finger?

> If, having better alternative, you still cling to the native console, you're the sole responsibility of all that happens to you.

So you decided by the powers vested in you that mintty is better than
ConEmu? That's oustanding...

I cannot find a single thing you contributed to this thread, except
trying to point out how dumb I must be. This will be my last post to
you, I fed the troll in you much more than I should have.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Sous Lesquels]

Thanks Larry.

> OK, good. We're on the same page then.  :-)

Indeed we are :)

>  it's hard to say there's going to be a good solution coming from Cygwin itself soon, unless there's some developer that wants to chase this in the near-term.

I certainly hope so. At least, to peek and determine if it's something
big or not. Console size to me sounds like some kind of buffer
overflow, not some intrinsically non-POSIX thing that MS console does.

This might even turn into a security issue if so. Hey, I have to get
this to be a high priority ;)

> I'm pretty sure that no-one actually meant to imply that you're an "ignorant quack".

Just "misunderstanding quack" then? :)

> this issue is likely to be viewed as relatively low priority, given the specifics of the issue and the alternatives.

Unfortunately agree with you on this, too...

> So I hope you find this feedback to be helpful in answering some of your inquiries.

It was helpful. Thanks for taking the time to reply, I appreciate that!

I'll go have a few more Cygwin crashes now ;) And hope endlessly till
some brave soul finds this thread :'( I'm off to other things, cheers!

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Warren Young]

On Aug 28, 2015, at 2:49 PM, Sous Lesquels <a9f54d2@gmail.com> wrote:
> 
> Console size to me sounds like some kind of buffer
> overflow

Quite possibly.

> not some intrinsically non-POSIX thing that MS console does.

Andrey wasn’t trying to tell you that the bug is happening because of a POSIX violation.  His brush-off reply was a reference to the fact that because mintty behaves much better with Cygwin programs, very few people will be using your particular combination of alternatives, so very few people will care to solve the problem.  And when it does get solved, very few people will benefit.  Maybe only you.

Therefore, don’t hold your breath waiting for someone else to fix it for you.
--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Warren Young]

> On Aug 28, 2015, at 7:23 AM, Sous Lesquels <a9f54d2@gmail.com> wrote:
> 
> I feel that with increasing monitors sizes == increasing window sizes,

You’re making an unwarranted assumption.  Increasing monitor sizes do not require increasing window widths.

As we saw in my original testing, the problem does not occur when the terminal window is 80 columns wide.

In fact, the default 80 column width is a bit too wide for optimal reading comprehension already:

  http://www.smashingmagazine.com/2014/09/balancing-line-length-font-size-responsive-web-design/

I’m not alone in recognizing this fact, and therefore choosing to use extra monitor space to increase the *height* of terminal windows only.  I generally keep windows taller than wide, arranged in 2-3 columns across on my 27” monitors.

The lone article I linked above is just a gloss over some very old, well-established science.  It’s why books are the size they are, and why newspapers print their material in multiple columns instead of spanning the whole page width.

I strongly encourage you to reconsider your practice of full-screening console windows.  ConEmu crashes aside, you are harming your own productivity.

(The same goes for any window containing primarily text: the message pane in your email client, your web browser, your desktop Kindle app…)

For Science, I decided to try and narrow the range where the symptom occurs.  I could not make it happen at 160 columns after three runs.  I failed again at 240.  Then I increased it to 300, and still failed: three runs, no calloc() abort.  

This whole time, I had the window at 64 lines high, so I tried increasing that to near my monitor’s height, 84 lines with the font settings I prefer.  Still no replication of the symptom.  

By this point, I had only about 3-4 mm of space around the window top-and-bottom, and about 1 cm to either side, so I finally full-screened the window, and *now* the symptom reoccured.

So Doctor Repin is right: don’t do that. :)

> I can change
> from ConEmu to mintty, but IMHO that's like saying I can use the
> stairs instead of an elevator in Burj Khalifa.

A more apt comparison is between stairs and ramps in a world where most people use wheels to get around, but you prefer the stairs.  You’ve discovered that the dust on the stairs occasionally catches fire when you run up them with a Roman candle in each hand.  So you complain that your leg hair is getting scorched, and are rejecting advice to either use the well-swept ramp or stop carrying flaming objects up the stairs.

Defaults matter.  The ramp is front-and-center when you walk in the main Cygwin doors, whereas the stairs are down a poorly-lit side hall, one turn to the left and two to the right, past the soda machine, and behind an unmarked door.   Your path will not be as well-traveled, and consequently will not be as well-maintained.

> Saying "it's ms bug", "it's a design choice", "it's a bug, but we
> don't have time / resources to fix it", "it happens so rarely, we
> don't care", "it's going to be fixed in 2030", etc. is fine with me.

How about, “Scratch your own itch.”  You have the source code and a replicable test case.

*I* have the source and a replicable test case, too, but I don’t have the itch.
--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Andrey Repin]

Greetings, Sous Lesquels!

>> I'm not in the mood of retyping the POSIX standard for you.

> But you are obviously always in the mood to be unhelpful...

If you do not like the answer to your question, it doesn't make the answer
wrong, or unhelpful, or what-you-have-called-it.

>> I'm personally acquainted with the creator of ConEmu and he's not working for Microsoft.

> And this breaks without ConEmu.

That's because of how ConEmu is implemented - it is a wrapper for native
console, not a separate implementation of it.

> If you forget I said that I use ConEmu
> and run my example in a native Microsoft-made console, it will break.
> So please clarify to me how this has to do with ConEmu?

You don't understand, what you are asking for, that's what it have to do.

>> Yet again, Cygwin tools themselves and terminal you use them in is two perpendicular things.

> So are Cygwin tools and airplanes. Or Cygwin tools and stick figures.
> What's your point?

My point is the intersection. Cygwin tools do not intersect with airplanes or
stick figures.
Your examples are not valid.

>> You know, what I can say about it?
>>
>> - Doctor, when I twist my finger this way, it hurts!
>> - Don't twist your finger this way.

> If you took a few minutes to think, you'd understand that in this case
> I have two choices - use mintty and have no breaks or use ConEmu and
> have breaks.

Since ConEmu is not a separate program, but merely a wrapper to native
console, you're not asking the right question.
Therefore, there's no right answer to give.

> The continuation of your imaginary dialogue above would be:

> - But doctor, it hurts any way I move my finger!

> What would the doctor say, stop using your finger?

It doesn't hurt when you don't twist it.

>> If, having better alternative, you still cling to the native console,
>> you're the sole responsibility of all that happens to you.

> So you decided by the powers vested in you that mintty is better than
> ConEmu? That's oustanding...

It isn't better or worse - it is DIFFERENT. Built for a different purpose with
different goals in mind.
However, if we narrow the selection choice to "works as Cygwin terminal",
ConEmu will have the same score as native windows terminal just by an
extension of being a wrapper for one, as it is viewed from Cygwin's side.

> I cannot find a single thing you contributed to this thread, except
> trying to point out how dumb I must be. This will be my last post to
> you, I fed the troll in you much more than I should have.

Now, dragging the topic into personal attacks would contribute even less.


-- 
With best regards,
Andrey Repin
Saturday, August 29, 2015 00:37:20

Sorry for my terrible english...


--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Christopher Faylor]

On Mon, Jul 21, 2014 at 12:32:34PM +0000, Nellis, Kenneth wrote:
>> From: sous lesquels
>> <snip> 
>> > If you can't wait, then read the message using your browser and click
>> > on the "Raw text" link near the top. The first line will say something
>> > like From cygwin-return-191383-listarch-cygwin=...
>> > Note the message number 191383.
>> > Then you send an empty message to cygwin-get.191383@cygwin.com and it
>> > will mail you back the specified message. You can then reply to it and
>> > your reply will be threaded.
>> Perfect, exactly what I was looking for. Agree it's not the most direct
>> method, but then again solves all the situations I could think of
>> requiring a physical email message that can be replied to.
>> 
>> Thanks for the tip Ken!
>
>Glad to help.
>I'm thinking it should be dirt simple for the web site maintainer
>to add a hyperlink right on the message web page, perhaps under the
>"Raw text" link, which would say something like "Request this message".
>It would simply be a mailto: link with the correct message number added.
>I'm thinking this could make life much easier for digest readers,
>like myself. In the example above, the link would be:
><a href="mailto:cygwin-get.191383@cygwin.com">Request this message</a>
>The only trick would be inserting the proper message number.

No, we're not going to change the way the web archive works.  There is
no easy way that the archiving software would know what the mailto: link
would be.  And, I'm not too interested in hacking at the archiver
anyway.

I'll say it again: Just add the In-Reply-To or References with the right
Message-ID and you'll get threading.

cgf

--
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

RE: Some programs (vi, ssh) crash when screen buffer height is big

[Nellis, Kenneth]

> From: sous lesquels
> <snip> 
> > If you can't wait, then read the message using your browser and click
> > on the "Raw text" link near the top. The first line will say something
> > like From cygwin-return-191383-listarch-cygwin=...
> > Note the message number 191383.
> > Then you send an empty message to cygwin-get.191383@cygwin.com and it
> > will mail you back the specified message. You can then reply to it and
> > your reply will be threaded.
> Perfect, exactly what I was looking for. Agree it's not the most direct
> method, but then again solves all the situations I could think of
> requiring a physical email message that can be replied to.
> 
> Thanks for the tip Ken!

Glad to help.
I'm thinking it should be dirt simple for the web site maintainer
to add a hyperlink right on the message web page, perhaps under the
"Raw text" link, which would say something like "Request this message".
It would simply be a mailto: link with the correct message number added.
I'm thinking this could make life much easier for digest readers,
like myself. In the example above, the link would be:
<a href="mailto:cygwin-get.191383@cygwin.com">Request this message</a>
The only trick would be inserting the proper message number.

--Ken Nellis

Re: Some programs (vi, ssh) crash when screen buffer height is big

[sous lesquels]

> If you can wait for the digest, you can simply open the selected message from
> the digest and reply to that, and it will be threaded.
Using Gmail, it doesn't seem to offer a way to see them as separate
mails or reply to a particular one, though. Oh, well...

> If you can't wait, then read the message using your browser and click on the
> "Raw text" link near the top. The first line will say something like
> From cygwin-return-191383-listarch-cygwin=...
> Note the message number 191383.
> Then you send an empty message to cygwin-get.191383@cygwin.com and it will
> mail you back the specified message. You can then reply to it and your reply
> will be threaded.
Perfect, exactly what I was looking for. Agree it's not the most
direct method, but then again solves all the situations I could think
of requiring a physical email message that can be replied to.

Thanks for the tip Ken!

--
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

RE: Some programs (vi, ssh) crash when screen buffer height is big

[Nellis, Kenneth]

> From: Christopher Faylor
> There is no automated way to do that if you are using the digest.  Digests
> are intended for casual perusal of the list, not for active communication.

FWIW, I get digest format, but still make threaded replies (such as this) with 
a few extra steps that may not be obvious. This presumes using Outlook. YMMV.

If you can wait for the digest, you can simply open the selected message from
the digest and reply to that, and it will be threaded.

If you can't wait, then read the message using your browser and click on the
"Raw text" link near the top. The first line will say something like
From cygwin-return-191383-listarch-cygwin=...
Note the message number 191383.
Then you send an empty message to cygwin-get.191383@cygwin.com and it will
mail you back the specified message. You can then reply to it and your reply 
will be threaded.

--Ken Nellis


--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Christopher Faylor]

On Fri, Jul 18, 2014 at 12:59:10PM -0400, sous lesquels wrote:
>Any suggestions? Or is this not as common use case as I think it is?

Craft your reply with the appropriate "In-Reply-To" header tag and it
will maintain threading.

There is no automated way to do that if you are using the digest.  Digests
are intended for casual perusal of the list, not for active communication.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[sous lesquels]

Thanks Larry.

> This is not the recommended way of handling this situation.  You end up
> with a ".new" extension if the DLL was in use at the time of your upgrade.
> In this case, setup*.exe schedules a replace of your existing DLL with the
> ".new" version on reboot.  So if you find such a file on your system, the
> sanctioned resolution to this is to reboot.

OK, thanks for clarifying the update process. I thought maybe setup
when started will try to update a file anyway (if not in use at that
time, even though it was in use before).

Note that I did not know there was "a situation" in the first place :)
I definitively rebooted multiple times in between and it looks like it
did not get replaced - maybe an issue with scheduling a replace?

> You must have subscribed to the list and requested a digest.
That I was.

> By default, any email replies to this list go to the list.
Makes sense, however it would not go to this thread, probably just
create a new thread, correct?

> The best way to get individual messages from this list that are easy
> to reply to is to subscribe without using the digest option
Agree, had I been subscribed, I would have gotten the message to reply
to, but I unfortunately was only getting digests.

Just to note - I'm not asking for the poster to reply to me, just
wondering if it's possible to somehow send a mail and tell the mailing
list software to thread beneath a specific node of the thread index.
E.g. put In-Repy-To: <msg ID> (which I can get from the raw text of
the post) in the body or something like that that I'm not aware of?

If not, there's no way to thread properly in various cases such as:

- I've posted something a month ago and don't want to be spammed by
unrelated posts (which would be hundreds in that time span), then a
reply comes
- I've accidentally deleted the mail
- I want to respond to a post that was posted before I subscribed

Any suggestions? Or is this not as common use case as I think it is?

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Larry Hall (Cygwin)]

On 07/18/2014 10:48 AM, sous lesquels wrote:
>> It's not reproducible for me.  I just tried your ssh scenario with a
>> 1000 and 2000 line buffers and it works fine for me every time, be it
>> with Cygwin 1.7.30 or the latest snapshot.  I also raised the number of
>> loops.  Is it possible that you're suffering a BLODA(*) problem?
>>
>>
>> Thanks,
>> Corinna
>
>> Confirmed.
>>
>> I tried up to 9999, the maximum allowed.
>>
>> This is under Windows 8.1 Pro, with Cygwin 1.7.30, both 32- and 64-bit.
>
> I was running under:
>
> CYGWIN_NT-6.1 1.7.29(0.272/5/3) 2014-04-07 13:46
>
> It might have been a feature present in 1.7.29.
>
> More likely, it was a installation issue. I had cygwin1.dll with
> 1.7.29 and cygwin1.dll.new with 1.7.30. I ran setup-x86_64.exe
> multiple times and it did nothing to upgrade it (I assume it renames
> cygwin1.dll.new to cygwin1.dll, correct?). No cywgin processes were
> running otherwise. What helped is to manually reinstall "cygwin"
> package. Now that I'm at 1.7.30, all seems OK. Probably just a version
> mismatch.

This is not the recommended way of handling this situation.  You end up
with a ".new" extension if the DLL was in use at the time of your upgrade.
In this case, setup*.exe schedules a replace of your existing DLL with the
".new" version on reboot.  So if you find such a file on your system, the
sanctioned resolution to this is to reboot.

> As a side topic, I did not get a mail with your (Corinna / Warren)
> replies, just a digest, and could not reply to it. Not sure how it
> will thread. Is there a way to somehow specify which post to reply to
> in the body of the mail, so that it threads as I want? As per
> https://sourceware.org/lists.html#what-software, ezmlm-idx is used and
> as per http://untroubled.org/ezmlm/faq/How-threading-works.html#How-threading-works
> it threads by subject, not using In-Reply-To or so. And even if it
> did, I cannot specify headers via Gmail (firewall, cannot use other
> email clients unfortunately). If not a simple answer, I'll open a
> separate thread.

You must have subscribed to the list and requested a digest.  By
default, any email replies to this list go to the list.  If you
want a direct copy, you have to ask for it and you rely on the
kindness of the responder to put in the extra effort to comply.
The best way to get individual messages from this list that are easy
to reply to is to subscribe without using the digest option.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[sous lesquels]

> It's not reproducible for me.  I just tried your ssh scenario with a
> 1000 and 2000 line buffers and it works fine for me every time, be it
> with Cygwin 1.7.30 or the latest snapshot.  I also raised the number of
> loops.  Is it possible that you're suffering a BLODA(*) problem?
>
>
> Thanks,
> Corinna

> Confirmed.
>
> I tried up to 9999, the maximum allowed.
>
> This is under Windows 8.1 Pro, with Cygwin 1.7.30, both 32- and 64-bit.

I was running under:

CYGWIN_NT-6.1 1.7.29(0.272/5/3) 2014-04-07 13:46

It might have been a feature present in 1.7.29.

More likely, it was a installation issue. I had cygwin1.dll with
1.7.29 and cygwin1.dll.new with 1.7.30. I ran setup-x86_64.exe
multiple times and it did nothing to upgrade it (I assume it renames
cygwin1.dll.new to cygwin1.dll, correct?). No cywgin processes were
running otherwise. What helped is to manually reinstall "cygwin"
package. Now that I'm at 1.7.30, all seems OK. Probably just a version
mismatch.

As a side topic, I did not get a mail with your (Corinna / Warren)
replies, just a digest, and could not reply to it. Not sure how it
will thread. Is there a way to somehow specify which post to reply to
in the body of the mail, so that it threads as I want? As per
https://sourceware.org/lists.html#what-software, ezmlm-idx is used and
as per http://untroubled.org/ezmlm/faq/How-threading-works.html#How-threading-works
it threads by subject, not using In-Reply-To or so. And even if it
did, I cannot specify headers via Gmail (firewall, cannot use other
email clients unfortunately). If not a simple answer, I'll open a
separate thread.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Warren Young]

On 7/17/2014 02:24, Corinna Vinschen wrote:
>
> It's not reproducible for me.  I just tried your ssh scenario with a
> 1000 and 2000 line buffers

Confirmed.

I tried up to 9999, the maximum allowed.

This is under Windows 8.1 Pro, with Cygwin 1.7.30, both 32- and 64-bit.

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]

On Jul 16 16:29, sous lesquels wrote:
> A few more things to add:
> 
> - This crashes under the regular Windows console, i.e. run cmd.exe,
> then bash, then follow the above
> - It also crashes under some other emulators (I actually noticed it
> under ConEmu, see
> https://code.google.com/p/conemu-maximus5/issues/detail?id=1644),
> though this is likely due to the fact the regular Windows console is
> used underneath
> - When I said "screen buffer size", I mean the option in the Windows
> console - right click on the cmd.exe taskbar, Properties, Layout tab,
> Screen Buffer Size / Height - I could reproduce with 1000. It does not
> seem to be reproducible with low values (e.g. I tried with 100, 200,
> 500 and it seemed to work - not sure if it would have broken later,
> but it's not always reproducible as it is with 1000+)

It's not reproducible for me.  I just tried your ssh scenario with a
1000 and 2000 line buffers and it works fine for me every time, be it
with Cygwin 1.7.30 or the latest snapshot.  I also raised the number of
loops.  Is it possible that you're suffering a BLODA(*) problem?


Thanks,
Corinna

(*) https://cygwin.com/faq/faq.html#faq.using.bloda

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Some programs (vi, ssh) crash when screen buffer height is big

[Christopher Faylor]

On Wed, Jul 16, 2014 at 04:29:54PM -0400, sous lesquels wrote:
>A few more things to add:
>
>- This crashes under the regular Windows console, i.e. run cmd.exe,
>then bash, then follow the above

You've discovered that Cygwin has limits.  You can't run it with console
windows that are too big.  Sorry.

cgf

--
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

Re: Some programs (vi, ssh) crash when screen buffer height is big

[sous lesquels]

A few more things to add:

- This crashes under the regular Windows console, i.e. run cmd.exe,
then bash, then follow the above
- It also crashes under some other emulators (I actually noticed it
under ConEmu, see
https://code.google.com/p/conemu-maximus5/issues/detail?id=1644),
though this is likely due to the fact the regular Windows console is
used underneath
- When I said "screen buffer size", I mean the option in the Windows
console - right click on the cmd.exe taskbar, Properties, Layout tab,
Screen Buffer Size / Height - I could reproduce with 1000. It does not
seem to be reproducible with low values (e.g. I tried with 100, 200,
500 and it seemed to work - not sure if it would have broken later,
but it's not always reproducible as it is with 1000+)

On Wed, Jul 16, 2014 at 4:10 PM, sous lesquels <a9f54d2@gmail.com> wrote:
> **** Environment
>
> CYGWIN_NT-6.1 1.7.29(0.272/5/3) 2014-04-07 13:46
> Windows 7
>
> **** Steps to reproduce the issue:
>
> - With vi.exe
>
> Execute the following bash script:
>
> #!/bin/bash
> for i in {1..123}; do
>   echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
>   head -n1000 /var/log/setup.log
> done
> vi /var/log/setup.log
>
> vi breaks with something as:
>
>       0 [main] vi 13200 C:\cygwin64\bin\vi.exe: *** fatal error -
> cmalloc would have returned NULL
> /4.sh: line 6: 13200 Hangup                  vi /var/log/setup.log
>
> (note 4.sh is the file name I used to put the above script in and run
> it from there) and leaves a vi.exe.stackdump with the following
> contents:
>
> Stack trace:
> Frame        Function    Args
> 001004D2D08  0018006F26E (001801E8666, 001801E8DD9, 00000000000, 00000229480)
> 001004D2D08  00180046E32 (0000022A4E8, FF000000808080, FFFF000000FF00,
> FF00FF000000FF)
> 001004D2D08  00180046E72 (001801E8643, 00000000000, 00000000000, 00000000000)
> 001004D2D08  00180043983 (00076D22F7E, 00000000000, 00000000000, 00000000000)
> 001004D2D08  0018007B781 (FFFF000000FF00, FF00FF000000FF,
> FFFFFF0000FFFF, 00180000088)
> 001004D2D08  0018007B91F (00000000000, 00000000000, 00000000000, 00000000000)
> 001004D2D08  0018007E024 (00000000000, 00000000000, 00000000000, 00000000000)
> 001004D2D00  001801266FD (00000000000, 00000000000, 1A1311121C011615,
> 001802E2788)
> 001004D4160  0018011197B (00000000000, 00000000000, 1A1311121C011615,
> 001802E2788)
> End of stack trace
>
> - With ssh.exe
>
> ssh to some machine (Linux in my case) and execute the following bash script:
>
> #!/bin/bash
> for i in {1..123}; do
>   echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
>   head -n1000 /var/log/dmesg
> done
> vi /var/log/dmesg
>
> ssh breaks with:
>
> 0 [main] ssh 12464 C:\cygwin64\bin\ssh.exe: *** fatal error - cmalloc
> would have returned NULL
>
> and leaves a ssh.exe.stackdump file in the current working directory
> with the following contents:
>
> Stack trace:
> Frame        Function    Args
> 006000A267F  0018006F26E (001801E8666, 001801E8DD9, 00000000000, 00000226B60)
> 006000A267F  00180046E32 (00000227BC8, FF000000808080, FFFF000000FF00,
> FF00FF000000FF)
> 006000A267F  00180046E72 (001801E8643, 00000000000, 00000000000, 00100000002)
> 006000A267F  00180043983 (00076D22F7E, 00000000000, 0018007B522, 0000000270E)
> 006000A267F  0018007B781 (FFFF000000FF00, FF00FF000000FF,
> FFFFFF0000FFFF, 00180000088)
> 006000A267F  0018007B91F (000000001DC, 00000000000, 00000000000, 00000000000)
> 006000A267F  0018007E024 (00600077990, 00000000007, 00600077990, 00000000007)
> 006000A0490  001801266FD (00100426798, 00000000000, 00000000000, 00000000000)
> 0060006E850  0018011197B (00000000000, 00000000000, 00000000000, 00000000000)
> 0060006E850  00000004000 (00000000000, 00000000000, 00000000000, 21EF00000000)
> 0060006E850  00100426798 (00000000000, 001004928A0, 2BE9E0C5343523AB,
> 00000228090)
> 0060006E850  00600068670 (001004928A0, 2BE9E0C5343523AB, 00000228090,
> 00000000000)
> 0060006E850  003FEF96000 (001004928A0, 2BE9E0C5343523AB, 00000228090,
> 00000000000)
> End of stack trace
>
> **** More information:
>
> - For both variants, you may need to tweak the number 123 in the for
> loop above or the location of files if you don't have these - they
> should be there, but if not pick any file with some log-like text in
> it (a few hundred lines should be enough)
>
> - The variants are just quick and dirty ways to reproduce - crashes
> happen in regular work in various situations (i.e. real scenarios, not
> contrived as above)
>
> - Crashes can be reproduced always
>
> - Taking the same steps as above when running from Cygwin terminal
> (i.e. the one that comes bundled with Cygwin itself) does not result
> in a crash

--
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

Some programs (vi, ssh) crash when screen buffer height is big

[sous lesquels]

**** Environment

CYGWIN_NT-6.1 1.7.29(0.272/5/3) 2014-04-07 13:46
Windows 7

**** Steps to reproduce the issue:

- With vi.exe

Execute the following bash script:

#!/bin/bash
for i in {1..123}; do
  echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
  head -n1000 /var/log/setup.log
done
vi /var/log/setup.log

vi breaks with something as:

      0 [main] vi 13200 C:\cygwin64\bin\vi.exe: *** fatal error -
cmalloc would have returned NULL
/4.sh: line 6: 13200 Hangup                  vi /var/log/setup.log

(note 4.sh is the file name I used to put the above script in and run
it from there) and leaves a vi.exe.stackdump with the following
contents:

Stack trace:
Frame        Function    Args
001004D2D08  0018006F26E (001801E8666, 001801E8DD9, 00000000000, 00000229480)
001004D2D08  00180046E32 (0000022A4E8, FF000000808080, FFFF000000FF00,
FF00FF000000FF)
001004D2D08  00180046E72 (001801E8643, 00000000000, 00000000000, 00000000000)
001004D2D08  00180043983 (00076D22F7E, 00000000000, 00000000000, 00000000000)
001004D2D08  0018007B781 (FFFF000000FF00, FF00FF000000FF,
FFFFFF0000FFFF, 00180000088)
001004D2D08  0018007B91F (00000000000, 00000000000, 00000000000, 00000000000)
001004D2D08  0018007E024 (00000000000, 00000000000, 00000000000, 00000000000)
001004D2D00  001801266FD (00000000000, 00000000000, 1A1311121C011615,
001802E2788)
001004D4160  0018011197B (00000000000, 00000000000, 1A1311121C011615,
001802E2788)
End of stack trace

- With ssh.exe

ssh to some machine (Linux in my case) and execute the following bash script:

#!/bin/bash
for i in {1..123}; do
  echo -e "\033[5A\033[50C\033[0;35mhello\033[0m"
  head -n1000 /var/log/dmesg
done
vi /var/log/dmesg

ssh breaks with:

0 [main] ssh 12464 C:\cygwin64\bin\ssh.exe: *** fatal error - cmalloc
would have returned NULL

and leaves a ssh.exe.stackdump file in the current working directory
with the following contents:

Stack trace:
Frame        Function    Args
006000A267F  0018006F26E (001801E8666, 001801E8DD9, 00000000000, 00000226B60)
006000A267F  00180046E32 (00000227BC8, FF000000808080, FFFF000000FF00,
FF00FF000000FF)
006000A267F  00180046E72 (001801E8643, 00000000000, 00000000000, 00100000002)
006000A267F  00180043983 (00076D22F7E, 00000000000, 0018007B522, 0000000270E)
006000A267F  0018007B781 (FFFF000000FF00, FF00FF000000FF,
FFFFFF0000FFFF, 00180000088)
006000A267F  0018007B91F (000000001DC, 00000000000, 00000000000, 00000000000)
006000A267F  0018007E024 (00600077990, 00000000007, 00600077990, 00000000007)
006000A0490  001801266FD (00100426798, 00000000000, 00000000000, 00000000000)
0060006E850  0018011197B (00000000000, 00000000000, 00000000000, 00000000000)
0060006E850  00000004000 (00000000000, 00000000000, 00000000000, 21EF00000000)
0060006E850  00100426798 (00000000000, 001004928A0, 2BE9E0C5343523AB,
00000228090)
0060006E850  00600068670 (001004928A0, 2BE9E0C5343523AB, 00000228090,
00000000000)
0060006E850  003FEF96000 (001004928A0, 2BE9E0C5343523AB, 00000228090,
00000000000)
End of stack trace

**** More information:

- For both variants, you may need to tweak the number 123 in the for
loop above or the location of files if you don't have these - they
should be there, but if not pick any file with some log-like text in
it (a few hundred lines should be enough)

- The variants are just quick and dirty ways to reproduce - crashes
happen in regular work in various situations (i.e. real scenarios, not
contrived as above)

- Crashes can be reproduced always

- Taking the same steps as above when running from Cygwin terminal
(i.e. the one that comes bundled with Cygwin itself) does not result
in a crash

--
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