Subject: Re: bug#32338: 26.1; term.el broken on macOS

From: Constantine Vetoshev <[email-masked]>
Date: Thu, 20 Sep 2018 07:15:17 -0700

On Wed, Sep 19, 2018 at 4:30 PM Noam Postavsky <[email-masked]> 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...)