GNU bug report logs -
#16796
24.3.50; global value of after-change-functions reset without error
Previous Next
Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>
Date: Tue, 18 Feb 2014 17:45:02 UTC
Severity: normal
Found in version 24.3.50
Fixed in version 25.1
Done: Alex <agrambot <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 16796 in the body.
You can then email your comments to 16796 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16796
; Package
emacs
.
(Tue, 18 Feb 2014 17:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Michael Heerdegen <michael_heerdegen <at> web.de>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 18 Feb 2014 17:45:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16796
; Package
emacs
.
(Thu, 08 Sep 2016 23:48:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 16796 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> 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:
>
> (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))))))
>
> 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.
I can reproduce this on 24.5 but not in 25.1. Can you reproduce this on 25.1
or up?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16796
; Package
emacs
.
(Thu, 08 Sep 2016 23:56:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 16796 <at> debbugs.gnu.org (full text, mbox):
Alex <agrambot <at> gmail.com> writes:
> > (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))))))
> >
> > 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.
>
> I can reproduce this on 24.5 but not in 25.1. Can you reproduce this
> on 25.1 or up?
No, seems I can't reproduce it with 25.1. I guess we can close this and
cross our fingers.
Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#16796
; Package
emacs
.
(Fri, 09 Sep 2016 00:21:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 16796 <at> debbugs.gnu.org (full text, mbox):
close 16796 25.1
quit
Michael Heerdegen <michael_heerdegen <at> web.de> writes:
> No, seems I can't reproduce it with 25.1. I guess we can close this and
> cross our fingers.
>
> Michael.
Great, I'll close this then.
bug marked as fixed in version 25.1, send any further explanations to
16796 <at> debbugs.gnu.org and Michael Heerdegen <michael_heerdegen <at> web.de>
Request was from
Alex <agrambot <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Fri, 09 Sep 2016 00:21:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 07 Oct 2016 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 314 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.