[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Strange behavior with 25.2 on macOS

From: Barry Warsaw
Subject: Strange behavior with 25.2 on macOS
Date: Thu, 03 Aug 2017 12:49:11 -0400
User-agent: Postbox 5.0.16 (Macintosh/20170718)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]