On Wed, Sep 19, 2018 at 4:30 PM Noam Postavsky wrote: > Do you mean Emacs itself is hitting this error and crashing, or > /bin/bash running inside *ansi-term* does? Can you run under a debugger > and get a backtrace? The error occurs inside Emacs. It does not matter which process I run under term, they all do this. I did a little more digging, and observed the following: 1. Right after executing /bin/bash, the Emacs process forks, which makes sense. However, immediately afterwards, both processes slam the CPU to nearly 100% (60% for the parent and 30% for the child). 2. When I Ctrl-C (sigint) the main process, it exits with this error message: 2018-09-20 07:01:57.542 Emacs[80069:65713609] *** -[NSAutoreleasePool release]: This pool has already been released, do not drain it (double release). 3. The child process does not respond to sigint, continues to consume heavy CPU, and requires a sigkill to terminate. 4. I am attaching DTrace files for the two processes. I took two samples of the main (parent) process, then a sample of the child process, and then a sample of the child process after sending the main process a sigint. 5. When I run Emacs 26.1 under lldb, everything works! No crashes, no error messages. So I can't provide a crash-time stack trace, at least not with this build. > Does it currently work fine on 25.3 (i.e., is it possible an OS update > caused this to stop working on earlier Emacs versions as well)? If you > load term.el from 25.3 into 26.1 does it work then? Everything works perfectly on 25.3. I had to revert to using 25.3 because of this problem. Same OS version. After copying term.el from 25.3 into 26.1 (and deleting term.elc), 26.1 still exhibits the bug. Something must have changed in the macOS-specific pieces of Emacs between 25.3 and 26.1 which started causing this crash. It's bizarre that the problem goes away when run under a debugger environment. (Sometimes I've seen this happen with a race condition or other contention which goes away when the program is slowed down a little...)