GNU bug report logs - #8764
24.0.50; cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'

Previous Next

Package: emacs;

Reported by: Christopher Browne <cbbrowne <at> afilias.info>

Date: Mon, 30 May 2011 17:53:02 UTC

Severity: normal

Tags: moreinfo

Found in versions 24.0.50, 24.4

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

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 8764 in the body.
You can then email your comments to 8764 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Mon, 30 May 2011 17:53:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christopher Browne <cbbrowne <at> afilias.info>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 30 May 2011 17:53:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Browne <cbbrowne <at> afilias.info>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50;
	cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds
	`max-lisp-eval-depth'
Date: Mon, 30 May 2011 12:56:36 -0400
The problem isn't within the running Emacs process, rather it's with the
build process for trunk.

Based on a latest "bzr pull" of trunk, the build fails thus:

make[2]: Entering directory `/opt/emacs/trunk/lisp'
Compiling cedet/semantic/bovine/c-by.el

In toplevel form:
cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'
make[2]: *** [cedet/semantic/bovine/c-by.elc] Error 1
make[2]: Leaving directory `/opt/emacs/trunk/lisp'
make[1]: *** [compile-main] Error 2
make[1]: Leaving directory `/opt/emacs/trunk/lisp'
make: *** [lisp] Error 2

At line 184, this file is defining the following object:

(defconst semantic-c-by--parse-table
....

I'm not sure where to proceed from here.  The default value is 600; I
don't know if fiddling that higher would actually help.
-- 
(reverse (concatenate 'string "ofni.sailifa" "@" "enworbbc"))
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Mon, 30 May 2011 19:03:01 GMT) Full text and rfc822 format available.

Message #8 received at 8764 <at> debbugs.gnu.org (full text, mbox):

From: David Engster <deng <at> randomsample.de>
To: Christopher Browne <cbbrowne <at> afilias.info>
Cc: 8764 <at> debbugs.gnu.org
Subject: Re: bug#8764: 24.0.50;
	cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds
	`max-lisp-eval-depth'
Date: Mon, 30 May 2011 21:01:07 +0200
Christopher Browne writes:
> make[2]: Entering directory `/opt/emacs/trunk/lisp'
> Compiling cedet/semantic/bovine/c-by.el
>
> In toplevel form:
> cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds `max-lisp-eval-depth'
> make[2]: *** [cedet/semantic/bovine/c-by.elc] Error 1
> make[2]: Leaving directory `/opt/emacs/trunk/lisp'
> make[1]: *** [compile-main] Error 2
> make[1]: Leaving directory `/opt/emacs/trunk/lisp'
> make: *** [lisp] Error 2
>
> At line 184, this file is defining the following object:
>
> (defconst semantic-c-by--parse-table
> ....
>
> I'm not sure where to proceed from here.  The default value is 600; I
> don't know if fiddling that higher would actually help.

It should. The build from CEDET-bzr uses a value of 1000 to compile the
resulting parser files. I'm actually a bit puzzled that this ever worked
reliably with the default value.

-David




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Mon, 30 May 2011 19:05:02 GMT) Full text and rfc822 format available.

Message #11 received at 8764 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Christopher Browne <cbbrowne <at> afilias.info>
Cc: 8764 <at> debbugs.gnu.org
Subject: Re: bug#8764: 24.0.50;
	cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds
	`max-lisp-eval-depth'
Date: Mon, 30 May 2011 16:04:09 -0300
> The problem isn't within the running Emacs process, rather it's with the
> build process for trunk.

It's a file that requires a lot of stack depth, indeed.

> I'm not sure where to proceed from here.  The default value is 600; I
> don't know if fiddling that higher would actually help.

The lisp/Makefile.in pushes it up to 1200 and AFAIK this is sufficient
to bootstrap.  But maybe there are cases where a recompile ends up
recompiling in a different order and so more of the files are still
uncompiled, thus needing more stack space.


        Stefan




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Mon, 30 May 2011 19:20:02 GMT) Full text and rfc822 format available.

Message #14 received at 8764 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Browne <cbbrowne <at> afilias.info>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 8764 <at> debbugs.gnu.org
Subject: Re: bug#8764: 24.0.50; cedet/semantic/bovine/c-by.el:184:1:Error:
	Lisp nesting exceeds `max-lisp-eval-depth'
Date: Mon, 30 May 2011 15:19:30 -0400
On Mon, May 30, 2011 at 3:04 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:
>> The problem isn't within the running Emacs process, rather it's with the
>> build process for trunk.
>
> It's a file that requires a lot of stack depth, indeed.
>
>> I'm not sure where to proceed from here.  The default value is 600; I
>> don't know if fiddling that higher would actually help.
>
> The lisp/Makefile.in pushes it up to 1200 and AFAIK this is sufficient
> to bootstrap.  But maybe there are cases where a recompile ends up
> recompiling in a different order and so more of the files are still
> uncompiled, thus needing more stack space.

Thanks for pointing out the location; I did a bit of "iterative
refinement" and found that 1635 was sufficient whilst 1625 failed.

That isn't quite a scientific evaluation of what ought to be
necessary, but it sure seems that the value can need to be higher than
1200, and it's pretty plausible that 1635 only helps until an extra
couple elements get added to the parser, increasing stack usage.




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Mon, 30 May 2011 22:16:01 GMT) Full text and rfc822 format available.

Message #17 received at 8764 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Christopher Browne <cbbrowne <at> afilias.info>
Cc: 8764 <at> debbugs.gnu.org
Subject: Re: bug#8764: 24.0.50;
	cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds
	`max-lisp-eval-depth'
Date: Mon, 30 May 2011 19:14:57 -0300
> It should. The build from CEDET-bzr uses a value of 1000 to compile the
> resulting parser files. I'm actually a bit puzzled that this ever worked
> reliably with the default value.

The lexbind changes to the byte-compiler require more stack depth, which
is why it may compile with 1000 under Emacs-24, but requires more under
Emacs-24.


        Stefan




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Mon, 30 May 2011 22:17:01 GMT) Full text and rfc822 format available.

Message #20 received at 8764 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Christopher Browne <cbbrowne <at> afilias.info>
Cc: 8764 <at> debbugs.gnu.org
Subject: Re: bug#8764: 24.0.50;
	cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds
	`max-lisp-eval-depth'
Date: Mon, 30 May 2011 19:15:59 -0300
> That isn't quite a scientific evaluation of what ought to be
> necessary, but it sure seems that the value can need to be higher than
> 1200, and it's pretty plausible that 1635 only helps until an extra
> couple elements get added to the parser, increasing stack usage.

Since 1200 seems sufficient during bootstrap, it would be worthwhile to
try and figure out what is different between your case and the
bootstrap case.


        Stefan




Information forwarded to owner <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Mon, 30 May 2011 22:51:01 GMT) Full text and rfc822 format available.

Message #23 received at 8764 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Christopher Browne <cbbrowne <at> afilias.info>
Cc: 8764 <at> debbugs.gnu.org
Subject: Re: bug#8764: 24.0.50;
	cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds
	`max-lisp-eval-depth'
Date: Mon, 30 May 2011 19:50:40 -0300
> The lexbind changes to the byte-compiler require more stack depth, which
> is why it may compile with 1000 under Emacs-24, but requires more under
> Emacs-24.

[ Right, now that was clear, wasn't it? ]
The first "Emacs-24" should read "Emacs-23".


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Mon, 03 Feb 2014 23:50:01 GMT) Full text and rfc822 format available.

Message #26 received at 8764 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 8764 <at> debbugs.gnu.org, Christopher Browne <cbbrowne <at> afilias.info>
Subject: Re: bug#8764: 24.0.50;
 cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds
 `max-lisp-eval-depth'
Date: Mon, 03 Feb 2014 15:48:37 -0800
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> That isn't quite a scientific evaluation of what ought to be
>> necessary, but it sure seems that the value can need to be higher than
>> 1200, and it's pretty plausible that 1635 only helps until an extra
>> couple elements get added to the parser, increasing stack usage.
>
> Since 1200 seems sufficient during bootstrap, it would be worthwhile to
> try and figure out what is different between your case and the
> bootstrap case.

More information was requested two years ago, but no further progress
has been made (and this seems to work for everybody else), so I'm
closing this bug report.  If this problem is still present, please
reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/




bug marked as fixed in version 24.4, send any further explanations to 8764 <at> debbugs.gnu.org and Christopher Browne <cbbrowne <at> afilias.info> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 03 Feb 2014 23:50:03 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. (Tue, 04 Mar 2014 12:24:05 GMT) Full text and rfc822 format available.

bug No longer marked as fixed in versions 24.4 and reopened. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 05 Nov 2021 18:49:02 GMT) Full text and rfc822 format available.

bug unarchived. Request was from Paul Eggert <eggert <at> cs.ucla.edu> to control <at> debbugs.gnu.org. (Fri, 05 Nov 2021 19:03:02 GMT) Full text and rfc822 format available.

bug No longer marked as fixed in versions 24.4 and reopened. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 05 Nov 2021 19:03:02 GMT) Full text and rfc822 format available.

bug Marked as found in versions 24.4. Request was from Paul Eggert <eggert <at> cs.ucla.edu> to control <at> debbugs.gnu.org. (Fri, 05 Nov 2021 19:05:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Fri, 05 Nov 2021 19:11:02 GMT) Full text and rfc822 format available.

Message #41 received at 8764 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 8764 <at> debbugs.gnu.org, Christopher Browne <cbbrowne <at> afilias.info>,
 David Engster <deng <at> randomsample.de>
Subject: cedet/semantic/bovine/c-by.el:184:1:Error: Lisp nesting exceeds
 `max-lisp-eval-depth'
Date: Fri, 5 Nov 2021 12:10:39 -0700
> it would be worthwhile to
> try and figure out what is different between your case and the
> bootstrap case.

I ran into this problem recently on Emacs master (commit 
133026c362eb27191d992fbf35727550804bfc96 dated today). I had recently 
done a 'git pull' into a working directory that hadn't been updated for 
some time. When I did the usual './autogen.sh; ./configure; make' I got 
the same diagnostic for c-by.el.

The problem persisted after I removed all *.elc files and then did a 
'make -j5' on a 4-core machine. The problem then went away when I did a 
plain 'make'.

One hypothesis is that c-by.el depends on some other .el file being 
compiled into *.elc form (rather than being present in only source 
form), and that using 'make -j5' causes 'make' on my platform to 
(unluckily) arrange for c-by.el to be compiled before the other *.elc 
file (whatever it is) is available.

c-by.el starts this way:

(require 'semantic/lex)
(eval-when-compile (require 'semantic/bovine))

so perhaps we should arrange for all the .elc files needed by 
semantic/lex and/or semantic/bovine to be present, before compiling c-by.el.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#8764; Package emacs. (Fri, 03 Dec 2021 21:22:01 GMT) Full text and rfc822 format available.

Message #44 received at 8764 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 8764 <at> debbugs.gnu.org, Christopher Browne <cbbrowne <at> afilias.info>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 David Engster <deng <at> randomsample.de>
Subject: Re: bug#8764: 24.0.50; cedet/semantic/bovine/c-by.el:184:1:Error:
 Lisp nesting exceeds `max-lisp-eval-depth'
Date: Fri, 03 Dec 2021 22:20:54 +0100
Paul Eggert <eggert <at> cs.ucla.edu> writes:

> One hypothesis is that c-by.el depends on some other .el file being
> compiled into *.elc form (rather than being present in only source
> form), and that using 'make -j5' causes 'make' on my platform to
> (unluckily) arrange for c-by.el to be compiled before the other *.elc
> file (whatever it is) is available.

I found a reproducer:

larsi <at> xo:~/src/emacs/trunk$ rm lisp/emacs-lisp/cconv.elc
larsi <at> xo:~/src/emacs/trunk$ ./src/emacs -batch --eval '(byte-compile-file "./lisp/cedet/semantic/bovine/c-by.el")'

In toplevel form:
lisp/cedet/semantic/bovine/c-by.el:198:1: Error: Lisp nesting exceeds ‘max-lisp-eval-depth’
larsi <at> xo:~/src/emacs/trunk$ ./src/emacs -batch --eval '(byte-compile-file "./lisp/emacs-lisp/cconv.el")'
larsi <at> xo:~/src/emacs/trunk$ ./src/emacs -batch --eval '(byte-compile-file "./lisp/cedet/semantic/bovine/c-by.el")'
larsi <at> xo:~/src/emacs/trunk$ 

And indeed:

larsi <at> xo:~/src/emacs/trunk$ rm lisp/emacs-lisp/cconv.elc lisp/cedet/semantic/bovine/c-by.elc
rm: cannot remove 'lisp/cedet/semantic/bovine/c-by.elc': No such file or directory
larsi <at> xo:~/src/emacs/trunk$ make -j8
make -C lib all
make -C doc/lispref info

[...]

make[2]: Entering directory '/home/larsi/src/emacs/trunk/lisp'
  ELC      emacs-lisp/cconv.elc
  ELC      cedet/semantic/bovine/c-by.elc

In toplevel form:
cedet/semantic/bovine/c-by.el:198:1: Error: Lisp nesting exceeds ‘max-lisp-eval-depth’
make[2]: *** [Makefile:312: cedet/semantic/bovine/c-by.elc] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/home/larsi/src/emacs/trunk/lisp'
make[1]: *** [Makefile:342: compile-main] Error 2
make[1]: Leaving directory '/home/larsi/src/emacs/trunk/lisp'
make: *** [Makefile:439: lisp] Error 2

Now, cconv.elc is already in COMPILE_FIRST...  and adding it to
MAIN_FIRST in addition doesn't seem to help.  It doesn't seem to
actually wait until compiling MAIN_FIRST is done before doing the rest?
(If I'm reading the Makefile correctly.)

Yup.  I've now separated out the MAIN_FIRST into its own target, and
that fixes this problem.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




bug marked as fixed in version 29.1, send any further explanations to 8764 <at> debbugs.gnu.org and Christopher Browne <cbbrowne <at> afilias.info> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 03 Dec 2021 21:22: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. (Sat, 01 Jan 2022 12:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 77 days ago.

Previous Next


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