Strange behavior with 25.2 on macOS

[Barry Warsaw <barry@python.org>]

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