inhibit-modification-hooks set to t globally

inhibit-modification-hooks set to t globally

[Nicolas Richard]

Hello,

It sometimes happen that my fontification doesn't work correctly
anymore. Until now I had never tried to understand why, and simply
restarted emacs. Now, I finally took a few minutes to understand : at
least this time, inhibit-modification-hooks was globally set to t.
Reverting that to nil fixed the problem.

Any idea how I can find what caused inhibit-modification-hooks to be
globally t ?

Thanks

-- 
Nicolas Richard

Re: inhibit-modification-hooks set to t globally

[Stefan Monnier]

> It sometimes happen that my fontification doesn't work correctly
> anymore. Until now I had never tried to understand why, and simply
> restarted emacs. Now, I finally took a few minutes to understand : at
> least this time, inhibit-modification-hooks was globally set to t.
> Reverting that to nil fixed the problem.

> Any idea how I can find what caused inhibit-modification-hooks to be
> globally t ?

My best guess is that an error happened while inhibit-modification-hooks
was let-bound, and that error dropped you in the debugger, and you did
not exit from the debugger (you just kept on editing instead).

I.e. when this happens, check your mode line.  If the mode looks like
"[(Foo Bar)]" instead of "(Foo Bar)", then it's probably what's
going on, or something related.


        Stefan

Re: inhibit-modification-hooks set to t globally

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Date: Wed, 24 Sep 2014 17:42:19 +0200
> 
> It sometimes happen that my fontification doesn't work correctly
> anymore. Until now I had never tried to understand why, and simply
> restarted emacs. Now, I finally took a few minutes to understand : at
> least this time, inhibit-modification-hooks was globally set to t.
> Reverting that to nil fixed the problem.
> 
> Any idea how I can find what caused inhibit-modification-hooks to be
> globally t ?

This variable is defined in C, so a watchpoint with a suitable
condition (to avoid false positives of local bindings) should be
enough to catch the villain.

Re: inhibit-modification-hooks set to t globally

[Nicolas Richard]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> My best guess is that an error happened while inhibit-modification-hooks
> was let-bound, and that error dropped you in the debugger, and you did
> not exit from the debugger (you just kept on editing instead).

I'm almost sure I tried hitting C-M-c, but there was "No recursive edit in
progress". (If it happens again I'll double check of course.)

-- 
Nicolas Richard

Re: inhibit-modification-hooks set to t globally

[Nicolas Richard]

Eli Zaretskii <eliz@gnu.org> writes:
>> Any idea how I can find what caused inhibit-modification-hooks to be
>> globally t ?
>
> This variable is defined in C, so a watchpoint with a suitable
> condition (to avoid false positives of local bindings) should be
> enough to catch the villain.

By looking at the source, I managed to find that I should "watch
globals.f_inhibit_modification_hooks", but I could not find a way to set
up a condition with "watch". Also I don't know what the condition should
be. Can you guide me a little more ?

Thank you,

-- 
Nicolas

Re: inhibit-modification-hooks set to t globally

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: help-gnu-emacs@gnu.org
> Date: Thu, 25 Sep 2014 13:14:46 +0200
> 
> By looking at the source, I managed to find that I should "watch
> globals.f_inhibit_modification_hooks", but I could not find a way to set
> up a condition with "watch". Also I don't know what the condition should
> be. Can you guide me a little more ?

Maybe the first thing to try is simply something like this:

 (gdb) watch globals.f_inhibit_modification_hooks if globals.f_inhibit_modification_hooks == Qt
 (gdb) commands
   > xbacktrace
   > continue
   > end

(To get the "xbacktrace" command, start GDB in the Emacs src/
directory, or manually type "source /path/to/emacs/src/.gdbinit" once
inside GDB.)

Then turn on logging in GDB:

 (gdb) set logging on

Then run Emacs with the "run" command, and use it as usual until you
have your problem reproduced.  You could then look inside the file
gdb.txt, where GDB logs all its output, for the last watchpoint break.

If the watchpoint gets hit a lot, then Emacs will run slower, but
hopefully not too slow to become unusable.

Hopefully, not many Lisp packages/functions let-bind this variable, so
you won't need to wade through too many false positives.  If that
strategy succeeds, no watchpoint conditions will be needed.

HTH

Re: inhibit-modification-hooks set to t globally

[Nicolas Richard]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> Cc: help-gnu-emacs@gnu.org
>> Date: Thu, 25 Sep 2014 13:14:46 +0200
>> 
>> By looking at the source, I managed to find that I should "watch
>> globals.f_inhibit_modification_hooks", but I could not find a way to set
>> up a condition with "watch". Also I don't know what the condition should
>> be. Can you guide me a little more ?
>
> Maybe the first thing to try is simply something like this:
>
>  (gdb) watch globals.f_inhibit_modification_hooks if globals.f_inhibit_modification_hooks == Qt
>  (gdb) commands
>    > xbacktrace
>    > continue
>    > end

I tried these, but testing it with (setq inhibit-modification-hooks t)
did not give anything in the log file, so I suspect I won't ever catch
anything.

If I use
(gdb) watch globals.f_inhibit_modification_hooks
instead, then I get *a lot* of output in the log file. AFAICT, it's
mostly (if not always) because of signal_after_change or
signal_before_change which both issue "specbind
(Qinhibit_modification_hooks, Qt);" at some point.

-- 
Nicolas Richard

Re: inhibit-modification-hooks set to t globally

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: help-gnu-emacs@gnu.org
> Date: Thu, 25 Sep 2014 17:16:54 +0200
> 
> I tried these, but testing it with (setq inhibit-modification-hooks t)
> did not give anything in the log file, so I suspect I won't ever catch
> anything.

What does "print Qt" produce in that build?

> If I use
> (gdb) watch globals.f_inhibit_modification_hooks
> instead, then I get *a lot* of output in the log file. AFAICT, it's
> mostly (if not always) because of signal_after_change or
> signal_before_change which both issue "specbind
> (Qinhibit_modification_hooks, Qt);" at some point.

You could put a breakpoint at entry to specbind with commands to
disable the watchpoint, and another one at exit from the function to
re-enable it.

Re: inhibit-modification-hooks set to t globally

[Nicolas Richard]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
>> I tried these, but testing it with (setq inhibit-modification-hooks t)
>> did not give anything in the log file, so I suspect I won't ever catch
>> anything.
>
> What does "print Qt" produce in that build?

(gdb) print Qt
$3 = 4611686018569228176

> You could put a breakpoint at entry to specbind with commands to
> disable the watchpoint, and another one at exit from the function to
> re-enable it.

Ok, I think I can do that and I will try that when I have some more
time.

Thanks,

-- 
Nicolas Richard

Re: inhibit-modification-hooks set to t globally

[Eli Zaretskii]

> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> Cc: help-gnu-emacs@gnu.org
> Date: Thu, 25 Sep 2014 17:32:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> From: Nicolas Richard <theonewiththeevillook@yahoo.fr>
> >> I tried these, but testing it with (setq inhibit-modification-hooks t)
> >> did not give anything in the log file, so I suspect I won't ever catch
> >> anything.
> >
> > What does "print Qt" produce in that build?
> 
> (gdb) print Qt
> $3 = 4611686018569228176

Sorry, it's my fault: the watchpoint should be defined like this
instead:

  (gdb) watch globals.f_inhibit_modification_hooks if globals.f_inhibit_modification_hooks != false
  (gdb) commands
    > xbacktrace
    > continue
    > end

> > You could put a breakpoint at entry to specbind with commands to
> > disable the watchpoint, and another one at exit from the function to
> > re-enable it.
> 
> Ok, I think I can do that and I will try that when I have some more
> time.

I think you will still need that with the watchpoint defined as above.

Re: inhibit-modification-hooks set to t globally

[Eli Zaretskii]

> Date: Thu, 25 Sep 2014 18:44:50 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > > You could put a breakpoint at entry to specbind with commands to
> > > disable the watchpoint, and another one at exit from the function to
> > > re-enable it.
> > 
> > Ok, I think I can do that and I will try that when I have some more
> > time.
> 
> I think you will still need that with the watchpoint defined as above.

Alternatively, you could only enable the watchpoint inside Flet and
FletX, since I think you are trying to catch let-binding of that
variable.

Re: inhibit-modification-hooks set to t globally

[Stefan Monnier]

> Hopefully, not many Lisp packages/functions let-bind this variable, so
> you won't need to wade through too many false positives.

Inhibit-modification-hooks gets let-bound *all the time* by things like
font-lock, after-change-functions, etc...

I see two ways for that variable to become globally non-nil:
- a braindead package uses `setq' on that variable.
- you bang on C-g enough that you end up hitting the infamous
  race-condition on unwind-protect (and let unbinding): unwind-protect
  forms get run when exiting because of C-g, but if you hit C-g while
  running those unwind forms, they may not run to completion, so you can
  end up with some of those unwind forms being "not run" (or only partly
  run).  I guess we could try to inhibit-quit while running the unwind
  forms to try and circumvent this problem, but such a change could
  introduce new bugs (if an unwind-form takes a long time to run,
  i.e. expect to be run without inhibit-quit).

Of course, there could also be a third way, but I can't imagine what
that would look like.


-- Stefan

Re: inhibit-modification-hooks set to t globally

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 25 Sep 2014 17:06:53 -0400
> 
>   I guess we could try to inhibit-quit while running the unwind
>   forms to try and circumvent this problem

I think we indeed should.

>   but such a change could introduce new bugs (if an unwind-form
>   takes a long time to run, i.e. expect to be run without
>   inhibit-quit).

I don't think this is a real danger.  If there are such unwinders out
there, they need to be redesigned/rewritten to finish in reasonably
short time.