bug#32883: 26.1; Emacs not response in shell mode

["alexei28" <alexei28@gmail.com>]

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Sunday, September 30, 2018 17:20
To: alexei28 <alexei28@gmail.com>
Cc: 32883@debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode

> From: "alexei28" <alexei28@gmail.com>
> Cc: <32883@debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 17:04:24 +0300
> 
> 1. M-x shell
> 2. Start some application that generate text about 1 minute  to 
> standard output.
> 3. Аt the fifth second press arrow up and move cursor to the center of 
> the screen (the text continues generated) 4. And now press Enter. It's 
> important to press Enter when text is continue to generate in shell 
> mode.
> 5. And Emacs will "freeze". Not response any more.
> Only "C-g" can help or not to unlock this.
> I always kill Emacs process from Task Manager

In my case, a single C-g stops waiting, and the application generating the
output resumes running.

Do you have a program named cat.exe somewhere?  If you do, can you use that
program instead of adb logcat -vtime?  You can invoke cat.exe like this:

  cat some-file

I do the another test.
1. M-x shell
2. Open some text file (about 2 MB) by command  "cat some_text.txt".
In shell mode something like this:

Microsoft Windows [Version 10.0.17134.285]
(c) 2018 Microsoft Corporation. All rights reserved.

d:\TEMP\temp>cat trace.log.2018-08-09

4. Start command
5. And while file is scrolling I press arrow up. As result cursor is on the
center of screen
6. Press Enter
7. And Emacs also "freeze". Not response. In this case Emacs is not response
only when file is opening (scrolling). 
8. After "cat" finish the Emacs is success unlock. In this case (file size =
2 MB) it's unlock after 30 seconds. 
But suppose file has size 200 MB. It's then unlock after one hour?
It's not good.






I used the output from logcat you sent instead of "some-file".  I cannot
cause Emacs to lock up this way.  I can always interrupt the waiting with a
single C-g.

In any case, when you press Enter, you actually send to the shell the line
that is at the cursor, so maybe you send something that runs some other
command in your case, I don't know.

Why do you need to type Enter as long as the command didn't finish producing
its output?

It's happens by accident.