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.

[dgutov]

@purcell Probably not. I don't see that in the format description.

[purcell]

@dgutov That’s a shame. :-(

[dgutov]

That may be because bytecode format is defined at the level of functions, not files, and tagging each with version could be considered wasteful. Or was considered a few decades ago.

If we look at at where compiled files usually come from, it's mostly two places: libs in the Emacs distribution that get compiled anew with each Emacs version, and the elpa directory. Very few users compile the files in their init directories manually.

As the main problem, we might want to extend package.el instead, to write down the version of Emacs the packages were installed with, and make it recompile all of them at startup if the version is lower than current. That would probably bring its own set of issues, though, starting with failed compilations.

[purcell]

As users, we could just start overriding our local elpa directory paths, and prefixing them with the maj/min emacs version.

[dgutov]

Ah, yes. That wouldn't be the worst approach, too.

[Wilfred]

Actually, Emacs does write the version number to .elc files. If you open a .elc file, it starts like this:

;ELC^W^@^@^@
;;; Compiled by  on Tue Feb  4 00:00:17 2014
;;; from file /home/wilfred/.emacs.d/elpa/ag-20140131.918/ag.el
;;; in Emacs version 24.3.1
;;; with all optimizations.

;;; This file uses dynamic docstrings, first added in Emacs 19.29.

;;; This file does not contain utf-8 non-ASCII characters,
;;; and so can be loaded in Emacs versions earlier than 23.