GNU bug report logs - #16796
24.3.50; global value of after-change-functions reset without error

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: 16796 <at> debbugs.gnu.org
Subject: bug#16796: 24.3.50; global value of after-change-functions reset without error
Date: Tue, 18 Feb 2014 18:43:36 +0100

Hello,

I'm working on a package that needs to install a function in (the global
binding of) `after-change-functions'.

I experience that the global value of `after-change-functions' is
randomly reset to nil, without any error involved or any error message
being printed.  I invested lots of time to preclude any error.

I installed a timer that frequently checks whether
`after-change-functions' had been reset.  A good situation to provoke
the reset was completing with helm and just typing in the minibuffer.
At random locations, the reset happened.  Note that there is no error
involved, nor does helm touch `after-change-functions'.


Here is a different example that "works" from emacs -Q:

--8<---------------cut here---------------start------------->8---
(progn
  
  (defun foo (&rest _) ())
  
  (add-hook 'after-change-functions 'foo)
  
  (defun complain ()
    (when (not (memq 'foo (default-value 'after-change-functions)))
      (message "Why does this happen?")
      (cancel-timer complain-timer)))
  
  (defvar complain-timer
    (run-with-idle-timer .03 .03 #'complain))

  (require 'cl-lib)
  (global-set-key
   [f9]
   (lambda () (interactive)
     (completing-read
      "Hit tab and C-g:  "
      (cl-loop for i from 1 to 100000
	       collect (format "%d" i))))))
--8<---------------cut here---------------end--------------->8---

Hit f9 and C-g one or two times.  I get "Why does this happen?", but not
always.  If I repeat the test several times, I'll always happen sooner
or later.

Here is the response I got from Kalle Olavi Niemitalo in emacs dev:

  I debugged this a bit, with my custom Emacs 23.0.51.  I don't
  know how much this machinery has changed in later versions.
  Emacs set Vquit_flag at:
  
    handle_interrupt
    tty_read_avail_input
    read_avail_input
    handle_async_input
    input_available_signal
    <signal handler called>
    mark_object
    Fgarbage_collect
    Ffuncall
    run_hook_list_with_args
    signal_after_change
    Fadd_text_properties
    Fput_text_property
    Fdisplay_completion_list
    internal_with_output_to_temp_buffer
    Fminibuffer_completion_help
    do_completion
    Fminibuffer_complete
    Ffuncall
    Fcall_interactively
  
  After Fgarbage_collect returned, Ffuncall called funcall_lambda,
  in which the QUIT macro detected the non-nil value of Vquit_flag
  and called Fsignal (Qquit, Qnil).  Because the quit was signaled
  within signal_after_change, after-change-functions were not
  restored.
  
  I don't see any reasonable way to prevent after-change-functions
  from being reset like this.

Thanks!  Kalle, does that mean that it won't be possible to fix this,
and that I shouldn't rely on `after-change-functions' being kept?

Do you know whether the buffer local binding is "safe"?

  Perhaps you could change your Emacs to break when the reset
  happens, and always run it in a debugger.  Make
  signal_before_change and signal_after_change maintain some kind
  of flag or nesting counter, and set conditional breakpoints in
  Fthrow and Fsignal.  That will get a false positive if the error
  is caught within the hook; but I don't think it happens often.

Uff, I'm afraid I must say that this is a bit above my (zerop) C skills.


Thanks,

Michael.




In GNU Emacs 24.3.50.6 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.6)
 of 2014-02-12 on drachen
Windowing system distributor `The X.Org Foundation', version 11.0.11405000
System Description:	Debian GNU/Linux testing (jessie)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.