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

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

[alexei28]

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

Hi!

Windows 10 (64 bit), Emacs 26.1

 

1.            I download Emacs 26 from here :
http://ftp.gnu.org/gnu/emacs/windows/emacs-26/emacs-26.1-x86_64.zip

2.            Unpack and run pure Emacs (no external packages)

3.            Connect android device to my computer

4.            M-x shell

5.            Run the next command adb logcat -vtime. Tool logcat- is a tool
from Google to see android's device logging. It's very helpful.

6.            This tool (logcat) generate many text interactively in shell.

7.            So I press button arrow up and move cursor to the center of
screen.

8.            Text is continues to be generated.

9.            And now I press button Enter

10.          As result Emacs not response any more. Show progress bar
forever. Nothing help. Only kill Emacs process from Task Manager

 

Why this is happened? is this a bug of Emacs?

 

Thanks.


[-- Attachment #2: Type: text/html, Size: 4094 bytes --]

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

[Eli Zaretskii]

> From: "alexei28" <alexei28@gmail.com>
> Date: Sun, 30 Sep 2018 10:47:27 +0300
> 
> 1.            I download Emacs 26 from here :
> http://ftp.gnu.org/gnu/emacs/windows/emacs-26/emacs-26.1-x86_64.zip
> 
> 2.            Unpack and run pure Emacs (no external packages)
> 
> 3.            Connect android device to my computer
> 
> 4.            M-x shell
> 
> 5.            Run the next command adb logcat -vtime. Tool logcat- is a tool from Google to see android's device
> logging. It's very helpful.
> 
> 6.            This tool (logcat) generate many text interactively in shell.
> 
> 7.            So I press button arrow up and move cursor to the center of screen.
> 
> 8.            Text is continues to be generated.
> 
> 9.            And now I press button Enter
> 
> 10.          As result Emacs not response any more. Show progress bar forever. Nothing help. Only kill Emacs
> process from Task Manager

How long did you wait?  Is it possible that it just takes a lot of
time for Emacs to display this text?

Did you try C-g several times?  Did that help?

Does it help to set w32-pipe-read-delay to zero?

If none of the above helps, can you save the output of "logcat -vtime"
in a file and post that file here?  Does visiting that file exhibit
similar problems, i.e. a long (or infinite) time needed for its
display?

Thanks.

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

[Eli Zaretskii]

[Please keep the bug address on the CC list.]

> From: "alexei28" <alexei28@gmail.com>
> Date: Sun, 30 Sep 2018 12:41:15 +0300
> 
> " How long did you wait?  "  - forever.

Please tell the approximate time.  I understand it was a long time,
but hardly "forever".

> " Did you try C-g several times?  " - yes, but it not help.
> " (setq w32-pipe-read-delay 0)" - not help

OK.

> "can you save the output of "logcat -vtime"" - it does not make sense
> because "logcat" generate unique text. You can do it yourself.
> Here steps:
> 1. Connect any android device to your comuter
> 2. Enable USB-debugging

You assume I have an Android device to do that, and that I'd agree to
enable USB debugging on such a device.  But those assumptions are not
necessarily true.

I asked whether saving the text to a file and visiting that file on
your system also locks up Emacs.  Did you try that?  If that doesn't
lock up Emacs, posting the file won't help.  Otherwise, please do post
such a file, I'd like to look at the actual text Emacs needed to deal
with in your case.

Thanks.

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

[Eli Zaretskii]

> From: "alexei28" <alexei28@gmail.com>
> Date: Sun, 30 Sep 2018 14:46:39 +0300
> 
> [Please keep the bug address on the CC list.]

You didn't, please do in the future.  It is important for this
discussion to be recorded by the bug tracker.

> Оne hour passed, but Emacs is not response. Show progress. 
> 'C-g' sometime help to unlock. But sometime not.

OK.

> OK. Not mandatory to start "adb logcat -vtime". You can start any process
> that generate text in standard output.

Then I cannot reproduce the problem on my system.  On my system, while
the process runs and generates the text, I can switch to another
buffer and invoke Emacs commands, like "C-x C-f" to visit other files,
and any other command.  Are you saying that you cannot type any
command while the command producing text runs in *shell*?

When you invoke "M-x shell", which shell runs in the *shell* buffer?
On my system it is cmd.exe.

> If I save text from shell to the file. And open this file by Emacs then no
> problem. Not lock Emacs. All work fine.
> I attached test file.

Thanks.

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

[Eli Zaretskii]

> From: "alexei28" <alexei28@gmail.com>
> Date: Sun, 30 Sep 2018 15:15:30 +0300

Please use "Reply to All" to reply to these messages, so that the bug
address gets a copy.  Thanks.

> > OK. Not mandatory to start "adb logcat -vtime". You can start any 
> > process that generate text in standard output.
> 
> Then I cannot reproduce the problem on my system.  On my system, while the
> process runs and generates the text, I can switch to another buffer and
> invoke Emacs commands, like "C-x C-f" to visit other files, and any other
> command.  Are you saying that you cannot type any command while the command
> producing text runs in *shell*?
> -  Yes, I can't do anything. Sometime "C-g" help to unlock this, but
> sometimes not.

So if you do this:

  M-x shell
  dir

Then Emacs is locked up?  Does it stop being locked up after the "DIR"
command finishes?

Does the problem happen if you invoke Emacs with "emacs -Q" from the
cmd command line?

> When you invoke "M-x shell", which shell runs in the *shell* buffer?
> On my system it is cmd.exe.
> 
> - Suppose I'm in the folder d:\temp. When I start "M-x shell" then open
> shell with the next text:
> 
> Microsoft Windows [Version 10.0.17134.285]
> (c) 2018 Microsoft Corporation. All rights reserved.
> 
> d:\TEMP>
> 
> I think this is a "cmd.exe"

Yes, this is cmd.exe.

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

[alexei28]

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Sunday, September 30, 2018 15:52
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>
> Date: Sun, 30 Sep 2018 15:15:30 +0300

Please use "Reply to All" to reply to these messages, so that the bug
address gets a copy.  Thanks.

> > OK. Not mandatory to start "adb logcat -vtime". You can start any 
> > process that generate text in standard output.
> 
> Then I cannot reproduce the problem on my system.  On my system, while 
> the process runs and generates the text, I can switch to another 
> buffer and invoke Emacs commands, like "C-x C-f" to visit other files, 
> and any other command.  Are you saying that you cannot type any 
> command while the command producing text runs in *shell*?
> -  Yes, I can't do anything. Sometime "C-g" help to unlock this, but 
> sometimes not.

So if you do this:

  M-x shell
  dir

Then Emacs is locked up?  Does it stop being locked up after the "DIR"
command finishes?

  M-x shell
  Dir

Work nice. Not lock of Emacs after finish command. 

Does the problem happen if you invoke Emacs with "emacs -Q" from the cmd
command line?

Yes, it's happen when start Emacs by "emacs - Q"

> When you invoke "M-x shell", which shell runs in the *shell* buffer?
> On my system it is cmd.exe.
> 
> - Suppose I'm in the folder d:\temp. When I start "M-x shell" then 
> open shell with the next text:
> 
> Microsoft Windows [Version 10.0.17134.285]
> (c) 2018 Microsoft Corporation. All rights reserved.
> 
> d:\TEMP>
> 
> I think this is a "cmd.exe"

Yes, this is cmd.exe.

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

[Eli Zaretskii]

> From: "alexei28" <alexei28@gmail.com>
> Cc: <32883@debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 15:59:36 +0300
> 
> So if you do this:
> 
>   M-x shell
>   dir
> 
> Then Emacs is locked up?  Does it stop being locked up after the "DIR"
> command finishes?
> 
>   M-x shell
>   Dir
> 
> Work nice. Not lock of Emacs after finish command. 

Hmm, so what other commands do cause Emacs to lock up?

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

[alexei28]

I noticed that only this command. 

When in shell mode (e.g. some application) generate interactively text in
standard output .

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Sunday, September 30, 2018 16:35
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 15:59:36 +0300
> 
> So if you do this:
> 
>   M-x shell
>   dir
> 
> Then Emacs is locked up?  Does it stop being locked up after the "DIR"
> command finishes?
> 
>   M-x shell
>   Dir
> 
> Work nice. Not lock of Emacs after finish command. 

Hmm, so what other commands do cause Emacs to lock up?

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

[Eli Zaretskii]

> From: "alexei28" <alexei28@gmail.com>
> Cc: <32883@debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 16:41:39 +0300
> 
> I noticed that only this command. 
> 
> When in shell mode (e.g. some application) generate interactively text in
> standard output .

Sorry, I don't understand.  What does "generate interactively" mean?

Earlier you said "you can start any process that generates text on
standard output", and "dir" is such a command.  If it's only the
single command "adb logcat -vtime", and no other command produces the
same problem, maybe that command is simply incompatible with Emacs?

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

[alexei28]

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Sunday, September 30, 2018 16:51
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 16:41:39 +0300
> 
> I noticed that only this command. 
> 
> When in shell mode (e.g. some application) generate interactively text 
> in standard output .

Sorry, I don't understand.  What does "generate interactively" mean?

Earlier you said "you can start any process that generates text on standard
output", and "dir" is such a command.  If it's only the single command "adb
logcat -vtime", and no other command produces the same problem, maybe that
command is simply incompatible with Emacs?

I mean some process (e.g. application) that generate text long time (e.g. 1
minutes) in standard output. 
The command "dir"  execute very quickly (about  1 second).

Test:

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

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

[Eli Zaretskii]

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

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

[alexei28]

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

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

[Eli Zaretskii]

> From: "alexei28" <alexei28@gmail.com>
> Cc: <32883@debbugs.gnu.org>
> Date: Sun, 30 Sep 2018 18:14:35 +0300
> 
> 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.

But that is what is supposed to happen.  When you press Enter,
shell-mode takes all the stuff between the point where you pressed
Enter and the end of output, and submits that to the shell.  Since
that's a lot of text, it could take a long time to process.

So just don't do that, it makes no sense to do that in the situation
you describe.

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

[alexei28]

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Sunday, September 30, 2018 20:06
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 18:14:35 +0300
> 
> 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.

But that is what is supposed to happen.  When you press Enter, shell-mode
takes all the stuff between the point where you pressed Enter and the end of
output, and submits that to the shell.  Since that's a lot of text, it could
take a long time to process.

So just don't do that, it makes no sense to do that in the situation you
describe.

So this is a not Emac's bug?
But  sometime I need to press Enter(while text is generate) because I , e.g.
want to insert some new text (e.g. notes) between existing text. 

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

[Michael Albinus]

"alexei28" <alexei28@gmail.com> writes:

> But  sometime I need to press Enter(while text is generate) because I , e.g.
> want to insert some new text (e.g. notes) between existing text. 

Then you shall press "C-q ENTER" instead.

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

[alexei28]

Here result:

C-q ENTER

^Minsert new text

How hide ^M ?

-----Original Message-----
From: Michael Albinus <michael.albinus@gmx.de> 
Sent: Monday, October 1, 2018 10:45
To: alexei28 <alexei28@gmail.com>
Cc: 'Eli Zaretskii' <eliz@gnu.org>; 32883@debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode

"alexei28" <alexei28@gmail.com> writes:

> But  sometime I need to press Enter(while text is generate) because I ,
e.g.
> want to insert some new text (e.g. notes) between existing text. 

Then you shall press "C-q ENTER" instead.

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

[Eli Zaretskii]

> From: "alexei28" <alexei28@gmail.com>
> Cc: <32883@debbugs.gnu.org>
> Date: Mon, 1 Oct 2018 10:09:37 +0300
> 
> So this is a not Emac's bug?

No, I don't think so.

> But  sometime I need to press Enter(while text is generate) because I , e.g.
> want to insert some new text (e.g. notes) between existing text. 

I suggest to use "C-q C-j" for that, i.e. quote the Enter key.

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

[alexei28]

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Monday, October 1, 2018 10:50
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: Mon, 1 Oct 2018 10:09:37 +0300
> 
> So this is a not Emac's bug?

No, I don't think so.

> But  sometime I need to press Enter(while text is generate) because I ,
e.g.
> want to insert some new text (e.g. notes) between existing text. 

I suggest to use "C-q C-j" for that, i.e. quote the Enter key.

OK. I will use "C-q C-j". It's a good solution. Thanks very much.

Emacs is cool :-)

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

[Eli Zaretskii]

> From: "alexei28" <alexei28@gmail.com>
> Cc: <32883@debbugs.gnu.org>
> Date: Mon, 1 Oct 2018 10:53:05 +0300
> 
> > I suggest to use "C-q C-j" for that, i.e. quote the Enter key.
> 
> OK. I will use "C-q C-j". It's a good solution. Thanks very much.
> 
> Emacs is cool :-)

Thanks, I'm therefore closing this bug.

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

[alexei28]

OK

-----Original Message-----
From: Eli Zaretskii <eliz@gnu.org> 
Sent: Monday, October 1, 2018 11:03
To: alexei28 <alexei28@gmail.com>
Cc: 32883-done@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: Mon, 1 Oct 2018 10:53:05 +0300
> 
> > I suggest to use "C-q C-j" for that, i.e. quote the Enter key.
> 
> OK. I will use "C-q C-j". It's a good solution. Thanks very much.
> 
> Emacs is cool :-)

Thanks, I'm therefore closing this bug.

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

[Michael Albinus]

"alexei28" <alexei28@gmail.com> writes:

> Here result:
>
> C-q ENTER
>
> ^Minsert new text
>
> How hide ^M ?

Try "C-q C-j".

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

[alexei28]

Yes, this is a good solution. 
Thanks

-----Original Message-----
From: Michael Albinus <michael.albinus@gmx.de> 
Sent: Monday, October 1, 2018 11:45
To: alexei28 <alexei28@gmail.com>
Cc: 'Eli Zaretskii' <eliz@gnu.org>; 32883@debbugs.gnu.org
Subject: Re: bug#32883: 26.1; Emacs not response in shell mode

"alexei28" <alexei28@gmail.com> writes:

> Here result:
>
> C-q ENTER
>
> ^Minsert new text
>
> How hide ^M ?

Try "C-q C-j".