occasional "Point after end of properties" error

[offby1]

This is company-20140805.2135; I'm using it via elpy version 1.5.1 (https://github.com/jorgenschaefer/elpy/) on

GNU Emacs 24.3.92.1 (x86_64-apple-darwin13.2.0, NS apple-appkit-1265.20) of 2014-07-08 on Eric-Hanchrows-iMac.local

Once or twice, as I was typing, I saw a message briefly appear in the echo area. I assumed it was an error, so I did M-x set-variable RET debug-on-error RET t RET, and was able to get this backtrace:

Debugger entered--Lisp error: (error "Company: Back-end (company-dabbrev-code company-gtags company-etags company-keywords) error \"Point 12569 after end of properties\" with args (candidates interfac)")
  signal(error ("Company: Back-end (company-dabbrev-code company-gtags company-etags company-keywords) error \"Point 12569 after end of properties\" with args (candidates interfac)"))
  error("Company: Back-end %s error \"%s\" with args %s" (company-dabbrev-code company-gtags company-etags company-keywords) "Point 12569 after end of properties" (candidates #("interfac" 0 8 (fontified nil face font-lock-string-face))))
  #[257 "\302\303   \304�!\300$\207" [(candidates #("interfac" 0 8 (fontified nil face font-lock-string-face))) company-backend error "Company: Back-end %s error \"%s\" with args %s" error-message-string] 6 "\n\n(fn ERR)"]((error "Point 12569 after end of properties"))
  funcall(#[257 "\302\303   \304�!\300$\207" [(candidates #("interfac" 0 8 (fontified nil face font-lock-string-face))) company-backend error "Company: Back-end %s error \"%s\" with args %s" error-message-string] 6 "\n\n(fn ERR)"] (error "Point 12569 after end of properties"))
  company-call-backend-raw(candidates #("interfac" 0 8 (fontified nil face font-lock-string-face)))
  company--fetch-candidates(#("interfac" 0 8 (fontified nil face font-lock-string-face)))
  company-calculate-candidates(#("interfac" 0 8 (fontified nil face font-lock-string-face)))
  #[0 "\n\203   �\nC\202\n��\211\205\245�\211@\300�9\204��\306�!\203<��9\2036��\307N\310=\2046��\307N?\205@�\311�!\205@��\312!\202@�\313�\312\"\240\210\300\242\203\236�\314\300\242!\203\230�\315\300\242!�\211�\301\316\f!\240\210\301\242:\204l�
\203\230�\317\320!\210\202\230�
\203t�\300\242��\2119\203\203�\321\322�!P��\202\211�\323\301\242@!\210\324\301\242!\210\325\326\327 \"\210\330\331!\210\332\333\301\242\"\210�A\266\202\202\n�\207" [(#("interfac" 0 8 (fontified nil face font-lock-string-face))) (nil) company-backend company-backends company-prefix company--manual-action functionp company-init t company-init-backend prefix company--multi-backend-adapter company--good-prefix-p company--prefix-str company-calculate-candidates message "No completion found" " " symbol-name company--update-group-lighter company-update-candidates run-hook-with-args company-completion-started-hook company-explicit-action-p company-call-frontends show throw --cl-block-nil-- company--manual-prefix company-lighter] 6 "\n\n(fn)"]()
  funcall(#[0 "\n\203   �\nC\202\n��\211\205\245�\211@\300�9\204��\306�!\203<��9\2036��\307N\310=\2046��\307N?\205@�\311�!\205@��\312!\202@�\313�\312\"\240\210\300\242\203\236�\314\300\242!\203\230�\315\300\242!�\211�\301\316\f!\240\210\301\242:\204l�
\203\230�\317\320!\210\202\230�
\203t�\300\242��\2119\203\203�\321\322�!P��\202\211�\323\301\242@!\210\324\301\242!\210\325\326\327 \"\210\330\331!\210\332\333\301\242\"\210�A\266\202\202\n�\207" [(#("interfac" 0 8 (fontified nil face font-lock-string-face))) (nil) company-backend company-backends company-prefix company--manual-action functionp company-init t company-init-backend prefix company--multi-backend-adapter company--good-prefix-p company--prefix-str company-calculate-candidates message "No completion found" " " symbol-name company--update-group-lighter company-update-candidates run-hook-with-args company-completion-started-hook company-explicit-action-p company-call-frontends show throw --cl-block-nil-- company--manual-prefix company-lighter] 6 "\n\n(fn)"])
  company--begin-new()
  company--perform()
  #[0 "\300 \207" [company--perform] 1 "\n\n(fn)"]()
  funcall(#[0 "\300 \207" [company--perform] 1 "\n\n(fn)"])
  company-auto-begin()
  company-idle-begin(#<buffer tests.py> #<window 584 on tests.py> 28851 4141)
  apply(company-idle-begin (#<buffer tests.py> #<window 584 on tests.py> 28851 4141))
  byte-code("r\301�\302H�\303H\"\210)\301\207" [timer apply 5 6] 4)
  timer-event-handler([t 21482 25348 209810 nil company-idle-begin (#<buffer tests.py> #<window 584 on tests.py> 28851 4141) nil 0])

[dgutov]

Thanks for the report. Alas, I've never encountered this, and the backtrace doesn't have contain enough information to debug. This might be a bug in Emacs, because the error seems to come from a low-level Emacs function.

Could you produce a full recipe how to reproduce this? What has to be in the buffer, its major mode, maybe the minor modes that trigger it.

The backtrace tells us this happens when the group of backends (company-dabbrev-code company-gtags company-etags company-keywords) is used. So you should be able to narrow it down by setting company-backends to ((company-dabbrev-code company-gtags company-etags company-keywords)), or, even better, seeing if you can reproduce it with company-backends containing a list with only one of these backends. (company-dabbrev-code) is a reasonable option to try first.

[offby1]

I'm sorry to say: it's extremely unlikely that I'll be able to come up with a repro recipe, since I don't remember what I was doing.

I also have only the vaguest idea of what company-mode is or does :-|

[dgutov]

That's too bad. If you come across the error again, please try to find out what conditions cause the problem.

I also have only the vaguest idea of what company-mode is or does :-|

It's a text completion framework. You don't really need to know how it works.

[dgutov]

I've just seen it, twice in a row, and then the error disappeared. Haven't managed to obtain a backtrace, but if you're tracking Emacs pretest and if you see it occur, you should be able to get a longer and more useful backtrace with the latest version of Company.

EDIT: Never mind. Got a backtrace. http://debbugs.gnu.org/18667

[dgutov]

I haven't seen this since. Probably a bug in Emacs, one we can't do much about. Hopefully it was only in that pre-release version.