Sporadic timer errors with Emacs HEAD

[purcell]

I use desktop.el to reopen buffers automatically when I restart Emacs, and when js2-mode buffers are restored, I get the following error with about 50% probability:

Debugger entered--Lisp error: (error "Invalid timer")
  signal(error ("Invalid timer"))
  error("Invalid timer")
  timer-set-function([t nil nil nil nil nil nil nil] js2-mode-idle-reparse (#<buffer boot.js>))
  js2-reparse()
  js2-mode()
  set-auto-mode-0(js2-mode nil)
  set-auto-mode()
  normal-mode(t)
  after-find-file(nil t)

Is this perhaps related to the apparent conclusion in this emacs bug filed by @dgutov that the js2 timer behavior may be incorrect?

[dgutov]

The timer behavior should be correct now, see also http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12447

timer-set-function is called here is in js2-mode-reset-timer (not in js2-reparse; incomplete backtrace?), where the timer it's passed can't really be invalid.

The only odd thing I can see is that (timer-create) returns [t nil nil nil nil nil nil nil nil] on my machine, which is one element more than your backtrace shows. Do you have a recent Emacs build?

[purcell]

Thanks for the follow-up.

js2-mode-reset-timer is a defsubst, and doesn't seem to show up in the backtrace.

I do have a recent Emacs, which indeed seems to use a 9-element timer vector, at least according to timerp.

On a hunch, I recompiled js2-mode, and now I'm not seeing the error even after restarting Emacs a few times. So perhaps the problem was caused by stale bytecode.

[purcell]

I'll go ahead and close this -- if the problem recurs, I'll reopen it and add details. Thanks.

[Wilfred]

I've just stumbled into this issue moving from Emacs 24.2 to 24.3. Recompiling js2-mode and restarting Emacs fixed it:

(byte-recompile-directory (expand-file-name "~/.emacs.d/elpa/js2-mode-20130307.2012/") 0 t)

[dgutov]

Yeah, that's exactly how Steve fixed it. Unfortunately, I don't think there's a good way around it.

timer-create has a compiler macro, and with Emacs 24.2 it's compiled to different code.

[CyborgMaster]

Yay! I've been trying to figure this one out for days. The byte recompile worked for me. This is very important information and should be made easier to find. Maybe we can put it in the MELPA package readme, or the readme of this repo, or a wiki page? It was rather hard for me to find the needed work around in this Closed issue from a year ago. (Good thing we have Google). Is there no way to fix it in the native MELPA package?

[dgutov]

Yeah, guess I'll put it in the readme, under Bugs. What were your symptoms? Did you see timer errors, or just broken syntax highlighting? Have you tried reinstalling instead of byte-recompiling?

[CyborgMaster]

I saw both broken syntax highlighting and the timer errors showed up in my message log. I didn't try reinstalling using package.el, although I probably should have (it said it was up to date and so I didn't think I needed to).

[CyborgMaster]

I don't remember, but I also might have upgraded emacs a few months back while trying to debug an issue with a different mode (enh-ruby-mode). If I did upgrade that is probably what caused it, so maybe its not a big issue. It's probably best practices to reinstall all packages when you upgrade emacs.

[dgutov]

It's probably best practices to reinstall all packages when you upgrade emacs.

Probably. Still, it's not really documented, and since people still stumble onto this bug, maybe it should be mentioned more prominently.

[CyborgMaster]

It would have helped me. :-)

[purcell]

@dgutov Is bytecode marked with the maj/min Emacs version which compiled it? I'm wondering if it's possible to write code which would block possibly-outdated bytecode from being loaded, or at least warn about it.