Strange behavior with 25.2 on macOS

Strange behavior with 25.2 on macOS

[Barry Warsaw]

I have two Macs, both of which run macOS 10.12.6, and both of which have 
Emacs 25.2 installed from source via homebrew.  Both are up-to-date in 
brew and in installed packages.  On one machine, Emacs is working great, 
but on the other, I'm seeing some very strange behavior with subprocess 
output hanging.  I'm wondering if anybody has seen similar issues, or 
has any suggestions for debugging.

Here's the most visible symptom:

In a shell buffer, I run the `tox` command to run the test suite for GNU 
Mailman 3, which is a Python project.  This spews a lot of output to 
stdout.  If I have that running in one window and go to another window 
with some code in it, and hit C-g in that window, the stdout spew from 
tox just stops.  It'll sit there forever until I hit any other key than 
C-g.  As soon as I do, all the buffered output gets printed and tox 
continues its progress.  It's pretty consistent behavior, and isn't 
really related to tox (it'll happen with anything that streams out lots 
of text in a shell).

Other things that stop output include:

* Going to the beginning of the code buffer and hitting C-p.
* Hitting ESC-x or ESC-: - in both cases the prompt appears in the 
minibuffer, but shell output stops.
* `C-x 5 o` to switch from the window displaying the code buffer to the 
window displaying the shell buffer.
* Going into the shell buffer and using either the `pushd` or `popd` 
bash commands.  I see the minibuffer echo the dir stack, but the shell 
prompt doesn't come back until I hit another key.  However, if the dir 
stack is empty and I popd, it comes back immediately.  cd to another 
directory can also hang the shell buffer.

I don't think it's just the shell though because I can also see a hang 
when invoking git commit through magit.  I see 'Running git commit --' 
in the minibuffer, but it's not until I hit another key or something 
that the commit buffer actually comes up.  I generally `git commit -a 
-v` but I don't know if that's relevant.

Other things that restart output include:

* Going to Activity Monitor, selecting the Emacs process and hitting 
Sample to collect process details.  When the shell buffer is stopped, it 
doesn't seem particularly hungry with CPU, disk, memory, or any other 
system resource.

The two machines are setup nearly identically.  One difference between 
them is that on the problematic machine I have the gnutls brew package 
installed (for gnupg), but I uninstalled that and reinstalled Emacs and 
verified that it makes no difference.  So yes, reinstalling Emacs 
doesn't solve the problem.  I haven't noticed any other weirdness with 
the machine exhibiting the Emacs problems.  I haven't completely 
verified that they both have the same packages installed, although what 
is installed are all up-to-date.

Any suggestions will be greatly appreciated!  The problem is so 
frustrating. ;)

Cheers,
-Barry

Re: Strange behavior with 25.2 on macOS

[Charles A. Roelli]

Can you reproduce this behavior from emacs -q (i.e., without any
personal configuration)?

I tried the following to see if I could reproduce it:

src/emacs -q
M-x shell RET
yes RET ; some command that spews a lot of output
C-x 5 2 ; create a new frame
C-x b *scratch* RET

Followed by these steps:

> * Hitting ESC-x or ESC-:
> * `C-x 5 o` to switch from the window displaying the code buffer to the
> window displaying the shell buffer.

But the issue did not occur (the amount of lines in the *shell* buffer
keeps on increasing without pause).



On 03/08/2017 18:49, Barry Warsaw wrote:
> I have two Macs, both of which run macOS 10.12.6, and both of which have
> Emacs 25.2 installed from source via homebrew.  Both are up-to-date in
> brew and in installed packages.  On one machine, Emacs is working great,
> but on the other, I'm seeing some very strange behavior with subprocess
> output hanging.  I'm wondering if anybody has seen similar issues, or
> has any suggestions for debugging.
>
> Here's the most visible symptom:
>
> In a shell buffer, I run the `tox` command to run the test suite for GNU
> Mailman 3, which is a Python project.  This spews a lot of output to
> stdout.  If I have that running in one window and go to another window
> with some code in it, and hit C-g in that window, the stdout spew from
> tox just stops.  It'll sit there forever until I hit any other key than
> C-g.  As soon as I do, all the buffered output gets printed and tox
> continues its progress.  It's pretty consistent behavior, and isn't
> really related to tox (it'll happen with anything that streams out lots
> of text in a shell).
>
> Other things that stop output include:
>
> * Going to the beginning of the code buffer and hitting C-p.
> * Hitting ESC-x or ESC-: - in both cases the prompt appears in the
> minibuffer, but shell output stops.
> * `C-x 5 o` to switch from the window displaying the code buffer to the
> window displaying the shell buffer.
> * Going into the shell buffer and using either the `pushd` or `popd`
> bash commands.  I see the minibuffer echo the dir stack, but the shell
> prompt doesn't come back until I hit another key.  However, if the dir
> stack is empty and I popd, it comes back immediately.  cd to another
> directory can also hang the shell buffer.
>
> I don't think it's just the shell though because I can also see a hang
> when invoking git commit through magit.  I see 'Running git commit --'
> in the minibuffer, but it's not until I hit another key or something
> that the commit buffer actually comes up.  I generally `git commit -a
> -v` but I don't know if that's relevant.
>
> Other things that restart output include:
>
> * Going to Activity Monitor, selecting the Emacs process and hitting
> Sample to collect process details.  When the shell buffer is stopped, it
> doesn't seem particularly hungry with CPU, disk, memory, or any other
> system resource.
>
> The two machines are setup nearly identically.  One difference between
> them is that on the problematic machine I have the gnutls brew package
> installed (for gnupg), but I uninstalled that and reinstalled Emacs and
> verified that it makes no difference.  So yes, reinstalling Emacs
> doesn't solve the problem.  I haven't noticed any other weirdness with
> the machine exhibiting the Emacs problems.  I haven't completely
> verified that they both have the same packages installed, although what
> is installed are all up-to-date.
>
> Any suggestions will be greatly appreciated!  The problem is so
> frustrating. ;)
>
> Cheers,
> -Barry
>
>
>

Re: Strange behavior with 25.2 on macOS

[Barry Warsaw]

Charles A. Roelli wrote:
> Can you reproduce this behavior from emacs -q (i.e., without any
> personal configuration)?

Good point, thanks, I should have thought of that.  So with -q it
doesn't seem to occur.  So clearly it must be one of the packages I have
installed.  I'll have to a/b it with the other machine to see what the
difference is.

Cheers,
-Barry