error "Lisp nesting exceeds `max-lisp-eval-depth'"

[hobbes]

Hi,

a problem with the latest beta (1.77-090430-02_30_54) on emacs-snapshot in debian sid.

emacs started with : emacs-snapshot -Q -l nxhtml/autostart.el

Then I do "M-x emacs-Q-nxhtml" just to be sure.

Then a simple RET in the scratch buffer brings the debugger, backtrace attached.

No problem in emacs22 on debian sid, only the snapshot is affected.

[lborgman (lennart-borgman)]

I can't reproduce this (I am using w32).

Could you please try looking at these in the *Scratch* buffer:

   F1 v mumamo-multi-major-mode

   F1 f syntax-ppss-flush-cache

[hobbes (hobbes-poukram)]

these bring the help with descriptions. I saved the description and I attach them to the bug report just in case it helps.

[lborgman (lennart-borgman)]

Thanks hobbes,

I am beginning to think that this is a problem with the debian snap-shot of Emacs. As I have said here

  https://bugs.launchpad.net/nxhtml/+bug/354363

it looks like it comes with an old nxml-mode package. Removing should probably solve the problem, but I am not sure.

Could you perhaps try to remove the nxml-mode that is in the site-lisp directory? (Remove the whole directory tree nxml-mode and the loading of the nxml-mode related files there.)

Or just wait until Romain Francoise have removed it from the snap-shot.

[hobbes (hobbes-poukram)]

Hello,

as explained in another bug, there is a separate nxml-mode in debian which should be used with emacs22 only.
So I removed it, and now I'm using the nxml-mode included in emacs23, patched to take care of https://bugs.launchpad.net/nxhtml/+bug/354363

But I still have the bug in the scratch buffer.

[lborgman (lennart-borgman)]

This one is hard. Just a thought: Did you byte-compile mumamo.el? (I hardly ever do that myself so I might have missed some problems there.)

[hobbes (hobbes-poukram)]

No, I just downloaded nxhtml and unzipped it in a folder. No byte-compilation, no fancy configuration, and I have the problem with and without -Q.

Don't hesitate to ask for more info or any test.

[lborgman (lennart-borgman)]

Thanks hobbes.

Could you please show the *Messages* buffer right after startup?

[hobbes (hobbes-poukram)]

see attached messages1

[lborgman (lennart-borgman)]

Thanks, I see nothing strange in your *Messages* so far.

But there is obviously something that goes wrong with the defadvice for syntax-ppss-flush-cache. Can you please try

  M-x emacs-Q-nxhtml

and then in the new Emacs in the *Scratch* buffer do

  F1 f syntax-ppss-flush-cache

and show me the output. Could you also show *Messages* after this, please.

[hobbes (hobbes-poukram)]

here it comes as attachements

[lborgman (lennart-borgman)]

Thanks, but still no clue. All I know is that something is wrong here since syntax-ppss-flush-cache should have been adviced at this point.

Could it be that the wrong files are loaded? What is the value of nxhtml-install-dir? Do

  F1 v nxhtml-install-dir

[hobbes (hobbes-poukram)]

/home/hobbes/nxhtml, which is the right path

[lborgman (lennart-borgman)]

Yes, that looks ok. I ask because I wonder if the correct mumamo.el is loaded, but I have no idea why it should not be the correct one. Can you please try the following.

- In the scratch buffer write

   (locate-library "mumamo")

   and then press C-x C-e to evaluate it. Is this the mumamo in the nxhtml/util sub directory?

- Can you open the mumamo.el in the sub directory nxhtml/util and evaluate the buffer by doing

   M-x eval-buffer

   Does that cure the problem you have? Can you show me what C-h v syntax-ppss-flush-cache is after this?

[hobbes (hobbes-poukram)]

mumamo.el is indeed in nxhtml/util

I restart emacs as writing in the Scratch buffer has launched the debugger.

I open mumamo.el, eval it, which gives this in the minibuffer :

ad-handle-definition: `syntax-ppss' got redefined

*Messages* attached

problem still there after all this

[hobbes (hobbes-poukram)]

please note that the latest beta modifies the behaviour (I haven't tried all steps, I went from 090501-14_11_45 to 090503-14_27_39)

Now the debugger doesn't fire up. I still have an error message :
ad-Orig-syntax-ppss-flush-cache: Lisp nesting exceeds `max-lisp-eval-depth'

[lborgman (lennart-borgman)]

Thanks, that you got the message that syntax-ppss got redefined is strange. I do not get any such message. Could you show the function description before and after you eval mumamo.el? Do

  M-x emacs-Q-nxhtml
  C-h f syntax-ppss

Then open mumamo.el and eval it and again do

  C-h f syntax-ppss

to get the function description.

[hobbes (hobbes-poukram)]

syntax-ppss-1 before evaling mumamo.el

[hobbes (hobbes-poukram)]

syntax-ppss-2 after evaling mumamo.el

[lborgman (lennart-borgman)]

Thanks hobbes,

It looks like the wrong mumamo.el is loaded, but I do not understand why. Let us try to find out which mumamo.el that is loaded from the beginning. Do you have a mumamo.elc in the same directory as mumamo.el? In that case please delete it.

Can you please add these lines to the end of mumamo.el:

  (when buffer-file-name (message "\nFinished evaluating %s\n" buffer-file-name))
  (when load-file-name (message "\nFinished loading %s\n" load-file-name))

Then look in *Messages* after M-x emacs-Q-nxhtml. What output do you find from the lines above?

Open mumamo.el and eval it. What output do you find now from the lines above in *Messages*?

[hobbes (hobbes-poukram)]

no mumamo.elc in the directory

attached messages10 is after emacs-Q-nxhtml

[hobbes (hobbes-poukram)]

attached message11 is after opening mumamo.el and evaling it

[lborgman (lennart-borgman)]

Thanks. Let us look further. Can you replace the corresponding two lines in autostart.el with these lines

    ;; Turn on `nxhtml-global-minor-mode' unconditionally
    (message "Before nxhtml-global-minor-mode, (featurep 'mumamo)=%s, mumamo path=%s"
             (featurep 'mumamo)
             (locate-library "mumamo"))
    (nxhtml-global-minor-mode 1)
    (message "After nxhtml-global-minor-mode, (featurep 'mumamo)=%s, mumamo path=%s"
             (featurep 'mumamo)
             (locate-library "mumamo"))

Then please show *Messages* after M-x emacs-Q-nxhtml.

[hobbes (hobbes-poukram)]

attached messages20

[lborgman (lennart-borgman)]

This is mysterious. Can you please send your mumamo.el?

[hobbes (hobbes-poukram)]

yes of course, but it's straight from your latest beta

[lborgman (lennart-borgman)]

Thanks hobbes, yes it is the one straight from the beta. So let us look at load-history instead. Can you show me the value of this please?

   C-h v load-history

[hobbes (hobbes-poukram)]

attached

[hobbes (hobbes-poukram)]

juste tried latest beta (1.77-090506-10_14_48), still no debugger but error message in *Messages* :

apply: Lisp nesting exceeds `max-lisp-eval-depth'

[lborgman (lennart-borgman)]

Thanks hobbes, I see nothing strange in the loading of nxhtml files either.

I wonder if it is something with the snap-shot build of Emacs itself, like in https://bugs.launchpad.net/nxhtml/+bug/354363

Could you build Emacs yourself perhaps?

[lborgman (lennart-borgman)]

Hm, or maybe start by just increasing max-lisp-eval-depth. And setting this

   (setq-default mumamo-use-condition-case nil)

before loading nXhtml and see if it will give some more useful message in the *Messages* buffer.

[hobbes (hobbes-poukram)]

max-lisp-eval-depth set to 10000 (also tried 1000000 to be sure) and (setq-default mumamo-use-condition-case nil), still error, see Messages attached as messages4

[hobbes (hobbes-poukram)]

IIRC https://bugs.launchpad.net/nxhtml/+bug/354363 is not tied to debian's snapshot, you submitted a patch for inclusion in emacs proper :-)

[lborgman (lennart-borgman)]

Hm, interesting that it happens during loading of nxhtml/autostart.el. Can you please put in

   (setq debug-on-error t)

at the top of that file so we can get a backtrace?

[hobbes (hobbes-poukram)]

attached backtrace2 is when I don't modify max-lisp-eval-depth

[hobbes (hobbes-poukram)]

backtrace1 is when I first set max-lisp-eval-depth to 100000

[lborgman (lennart-borgman)]

Thanks, I have asked for some help on Emacs Devel. I do not know if anyone can understand what is happening though.

Here are some simple instructions for building Emacs on Debian yourself from current CVS sources that I found in a message on that list:

  $ cvs -d:pserver:<email address hidden>:/sources/emacs co emacs
  $ cd emacs
  $ ./configure
  $ make bootstrap
  $ make
  $ ./src/emacs -Q

It would be very good if you could try that.

[lborgman (lennart-borgman)]

I got an answer from Klaus: http://lists.gnu.org/archive/html/emacs-devel/2009-05/msg00188.html

hobbes, could you please replace syntax-ppss-flush-cache in mumamo.el with this one:

(defadvice syntax-ppss-flush-cache (around
                                    mumamo-advice-syntax-ppss-flush-cache
                                    activate
                                    compile
                                    )
  "Support for mumamo.
See the defadvice for `syntax-ppss' for an explanation."
  (if (not mumamo-multi-major-mode)
      ad-do-it
    (let ((pos (ad-get-arg 0)))
      (let* ((chunk-at-pos (when (and (boundp 'mumamo-multi-major-mode)
                                      mumamo-multi-major-mode)
                             (mumamo-find-chunks pos "syntax-ppss-flush-cache"))))
        (if chunk-at-pos
            (let* ((syntax-ppss-last (overlay-get chunk-at-pos 'syntax-ppss-last))
                   (syntax-ppss-cache (overlay-get chunk-at-pos 'syntax-ppss-cache)))
              ;;(setq ad-return-value ad-do-it)
              ad-do-it
              (overlay-put chunk-at-pos 'syntax-ppss-last syntax-ppss-last)
              (overlay-put chunk-at-pos 'syntax-ppss-cache syntax-ppss-cache))
          ;;(setq ad-return-value ad-do-it)
          ad-do-it
          )))))

[hobbes (hobbes-poukram)]

just compiled emacs from cvs, and the error disappears

tried to replace syntax-ppss-flush-cache with the above code, which doesn't change anything in emacs-snapshot

[lborgman (lennart-borgman)]

Thanks hobbes. If you look in the answers to the question on Emacs Devel (see link above) then there is an answer from Stefan Monnier now where he says

> So ad-Orig-syntax-ppss-flush-cache is now a function that calls
> ad-Orig-syntax-ppss-flush-cache rather than being the original function
> bound to syntax-ppss-flush-cache. This shouldn't happen.
> To see it, try M-: (symbol-function 'ad-Orig-syntax-ppss-flush-cache).
>
> It means that it's either a bug in advice.el or that the function was
> manipulated in odd ways which confused advice, or something like that.

Can you please try that in both your emacs versions?

[hobbes (hobbes-poukram)]

with emacs-snapshot : attached messages5-snapshot

[hobbes (hobbes-poukram)]

with emacs-cvs : attached messages5-cvs

[lborgman (lennart-borgman)]

What does

   C-h f syntax-ppss-flusch-cache

say in the cvs version after starting with

  emacs-Q-nxhtml

[hobbes (hobbes-poukram)]

attached (by the way, mumamo.el is still modified with the above code, I hope this doesn't interfere...)

[lborgman (lennart-borgman)]

Thanks. No, I wanted you to change syntax-ppss-flush-cache as above and use that version of mumamo.el for both the snap-shot and the cvs Emacs. Do I understand you correctly that you have done that?

The output of C-h f syntax-ppss-flush-cache looks ok in cvs Emacs, ie the output says that the function is adviced. For the snap-shot Emacs it did not say that (if I did not misunderstand something).

This is very strange. Could you please clarify again here which snap-shot of Emacs you are using?

[hobbes (hobbes-poukram)]

ok, that's what I did : modified mumamo.el used in both emacs-cvs and emacs-snapshot.

you are right : in emacs-snapshot, syntax-ppss-flush-cache is not adviced according to C-h f

my version of emacs-snapshot is 1:20090501-1, taken on http://emacs.orebokech.com/ for debian sid

[hobbes (hobbes-poukram)]

just upgraded to today's emacs-snapshot (1:20090509-1), which still breaks nxhtml

[lborgman (lennart-borgman)]

Hi hobbes,

New tip from Sven Joachim, can you please show the output from

   M-x list-load-path-shadows

for both the cvs and the snap-shot versions?

[hobbes (hobbes-poukram)]

file list-load-path-shadows.snapshot attached for emacs-snapshot

much simpler for emacs-cvs : No Emacs Lisp load-path shadowings were found

[lborgman (lennart-borgman)]

Thanks hobbes. I could not find any special there (but I asked on Emacs Devel too).

However I think Romain Francoise have found the solution! Hurray!

From Francoise I got:

> the issue. There seems to be a problem with the way mumamo sets up
> its advice; it does:
>
> | (defadvice syntax-ppss-flush-cache (around
> | mumamo-advice-syntax-ppss-flush-cache
> | activate
> | compile
> | )
>
> which defines the advice, activates it *and* asks for compilation of
> the function. Then at the end of the file, it does:
>
> | (if t
> | (progn
> | (ad-activate 'syntax-ppss)
> | (ad-activate 'syntax-ppss-flush-cache)
> | (ad-activate 'syntax-ppss-stats)
> | (ad-activate 'rng-do-some-validation-1)
> | (ad-activate 'rng-mark-error)
> | (ad-activate 'xmltok-add-error)
> | )
>
> Which activates the advice again, but this time without asking for
> compilation. Whether or not the function is compiled then depends
> on the value of `ad-default-compilation-action', whose value depends
> on whether or not `byte-compile' is loaded (which can be influenced
> by other factors). (The same for all defadvice calls in mumamo.el.)
>
> The double activation with different flags seems to trigger a bug in
> Emacs, causing infinite recursion when jit-lock is invoked via
> `after-change-functions'. Unfortunately I can't seem to isolate a
> small test case to reproduce this without mumamo.

hobbes, can you please comment out this double activation? (I can't send a new mumamo.el at the moment.)

[hobbes (hobbes-poukram)]

hi, I commented the line with :

(ad-activate 'syntax-ppss-flush-cache)

and no error anymore :-)

[lborgman (lennart-borgman)]

Hi hobbes, please test the latest beta that I just uploaded. This defadvice things makes me nervous.

[hobbes (hobbes-poukram)]

great, no problem anymore, thanks a lot :-)

[lborgman (lennart-borgman)]

Thanks :-)