Killing multi-term causes errors in *Messages*

[kini]

Do SPC a s t ESC SPC b k RET y. In the *Messages* buffer, the following appears:

Buffer "*terminal<1>*" has a running process; kill it? (y or n) y
error in process filter: Selecting deleted buffer [2 times]

[lazywithclass]

I've tried this using version 0.100.1 and I don't see that error.

Is this still an issue for you?

[kini]

Nope. Thanks for checking up on it!

[kini]

Actually, never mind. I'm still able to reproduce this, but only sporadically. Sometimes the error occurs, and sometimes it doesn't. Switching to a different buffer before spawning the terminal seems to increase the likelihood of the error occurring, but doesn't guarantee it. Very mysterious...

Here's the traceback I get when I run M-x toggle-debug-on-error RET before starting the experiment:

Debugger entered--Lisp error: (error "Selecting deleted buffer")
  term-emulate-terminal(#<process terminal<1>> "^\\")

Not a very useful backtrace, as you can see...

[kini]

From #emacs IRC:

<forcer> kini: If it is only one line in the backtrace, then most likely from C
         - which is a bit weird
<kini> huh.
<forcer> kini: Ah, that is a process filter - it is called from C with data
         received from the program running in term
<kini> forcer: well, is it the whole backtrace though? At least, that one line
       is the only thing showing up in the window (other than the line with the
       error that triggered the debugger entry), but maybe there's more that's
       being hidden somehow?
<kini> oh?
<forcer> And yes, then it is the whole backtrace
<kini> thanks, that's a lead, I guess... hmm
<forcer> kini: What error is it?
<kini> full backtrace:
<kini> Debugger entered--Lisp error: (error "Selecting deleted buffer")
<kini> term-emulate-terminal(#<process terminal<1>> "^\\")
<kini> this is after killing a terminal buffer that has a shell running in it,
       i.e. Emacs has prompted me to kill the running process. So you're saying
       that emacs still receives stuff (namely "^\\") from the shell after it
       has been killed?
<forcer> kini: Yes, looks like. Possibly some kind of race condition.
<kini> well I tried setting the debugger to break every time the
       term-emulate-terminal function was entered, and it seems to be entered
       every time something gets printed to the buffer
<kini> either by the shell or by me typing a character, but I guess the latter
       is actually the shell echoing back the character I typed?
<forcer> kini: That's what a process filter does, yes
<forcer> Yes
<kini> so I imagine that Emacs is supposed to be shutting down the process
       filter immediately after killing the process and before killing the
       buffer, but in fact what happens is that it kills the process (i.e. sends
       it a sigterm), kills the buffer, and then kills the process filter, but
       the shell sends "^\\" after being receiving the kill signal but before
       dying and it gets picked up by the process filter before the filter is
       shut down but after the buffer is already gone
<kini> ouch
<kini> I guess I should try to reproduce it with `emacs -Q`
<forcer> And report a bug, yes.

So perhaps it is an Emacs bug. I have so far not succeeded in reproducing it with emacs -Q, though...

[StreakyCobra]

I can't reproduce this issue.

@kini Does this still happen to you with the last Spacemacs version and packages up-to-date?

[kini]

As I said in my earlier comment, I could only reproduce this sporadically. On the latest spacemacs it seems harder than back then -- I just tried a couple dozen times and couldn't get it to happen. Could be because we're using "pop" shells now, which weren't in spacemacs when I reported this bug.

Let's close this since it seems so hard to reproduce.

[kini]

(BTW, thanks for following up on the issue, @StreakyCobra!)

[StreakyCobra]

My pleasure :-) Feel free to open a new issue if you have some news about it!