Commit fdb4f6635351b3f3b15b5e948c39e9efcdd615df causing Emacs to crash for me

[Timothy Harper]

On Aug 23, 2011, at 7:05 PM, Timothy Harper wrote:

> I don't understand why, but this commit:
> 
> http://gitorious.org/evil/evil/commit/fdb4f6635351b3f3b15b5e948c39e9efcdd615df
> 
> … has caused emacs to start crashing for me.
> 
> A video to prove I'm not crazy:
> 
> http://screencast.com/t/58vWTsW0TTh
> 
> I'm using Vanilla Emacs for OS X, 23.3, downloaded here: http://emacsformacosx.com/
> 
> Crash dump: http://pastie.org/2419689
> 
> I'm betting it's an Emacs bug that is being surfaced by that change, because it should not be possible to crash emacs by writing emacs lisp like that.
> 
> Tim

After some experimenting, I was able to narrow down the cause of the crash to lines 17-19:

http://gitorious.org/evil/evil/blobs/fdb4f6635351b3f3b15b5e948c39e9efcdd615df/evil-integration.el#line17

It is specifically triggered by executing the following (generated by lines 18-19)

(eval-after-load 'comint
  `(evil-make-overriding-map comint-mode-map))

If I replace 17-19 with that bit of code, it crashes. If I do it with any other mode in evil-intercept-maps, it doesn't crash.

If I evaluate the above after emacs has started successfully, it doesn't invoke a crash. In order to crash the code must be evaluated during emacs initialization.

A work-around then, I propose, to those experiencing a similar problem, is to change the value evil-overriding-maps to omit the comint override. As a more long term fix… well, I don't know where to start. It's vague to me why this would be causing a crash, and I'm not sure if it's easy to reproduce (if it's an interaction with something else I am using in Emacs or not…).

Tim