GNU bug report logs - #10034
24.0.91; max-specpdl-size error

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10034 in the body.
You can then email your comments to 10034 AT debbugs.gnu.org in the normal way.

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

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

From: nyc4bos <at> aol.com
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.91; max-specpdl-size error
Date: Sat, 12 Nov 2011 23:46:37 -0500

I was playing around with built-in GnuTLS and the funtions
`open-gnutls-stream' and `gnutls-negotiate' to try to get
trustfiles to work on Windows. (GnuTLS doesn't support a "-CApath"
option where you can specify a directory where PEM files lives,
unfortunately, unlike OpenSSL).

I would create a GnuTLS process via:

(with-temp-buffer
(open-gnutls-stream "tls" "tls-buffer" "imap.aim.com" 993))

and

(gnutls-negotiate :process (open-network-stream "tls" "tls-buffer"
                     "imap.aim.com" 993)
                    :type 'gnutls-x509pki
                    :trustfiles trustfiles
                    :hostname host)


When I didn't see a successful verification message, i.e. warnings:

gnutls.c: [1] (Emacs) certificate signer was not found: imap.aim.com

I would kill the "tls-buffer" (hence killing the GnuTLS process) and
the buffer would be killed and I would see the expected message:

gnutls.c: [2] (Emacs) Deallocating x509 credentials

I would then make modifications to the definition of `trustfiles' or
PEM files, etc. and try again.

I would do this iteration many times.

Eventually, I would get into a state where I couldn't do much, seeing
messages like:

window-min-size-1: Variable binding depth exceeds max-specpdl-size

I then could only kill Emacs.


In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600)
 of 2011-11-07 on MARVIN
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.6) --no-opt --cflags -I"D:/devel/emacs/libs/libXpm-3.5.8/include" -I"D:/devel/emacs/libs/libXpm-3.5.8/src" -I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include" -I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include" -I"D:/devel/emacs/libs/giflib-4.1.4-1/include" -I"D:/devel/emacs/libs/jpeg-6b-4/include" -I"D:/devel/emacs/libs/tiff-3.8.2-1/include" -I"D:/devel/emacs/libs/gnutls-2.10.1/include" --ldflags -L"D:/devel/emacs/libs/gnutls-2.10.1/lib"'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US
  value of $XMODIFIERS: nil
  locale-coding-system: cp949
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<return> n <return> C-x b * M e <tab> <return> C-r 
g n u t C-a C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r 
C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r 
C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r C-r 
C-r C-r C-r C-v C-s C-s <help-echo> <help-echo> <help-echo> 
<help-echo> C-x b * s c <tab> C-g <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<help-menu> <send-emacs-bug-report>

Recent messages:
gnutls.c: [2] ASSERT: ../../../src/gnutls-2.10.5/lib/gnutls_record.c:918

gnutls.c: [2] (Emacs) Deallocating x509 credentials
gnutls.c: [2] ASSERT: ../../../src/gnutls-2.10.5/lib/gnutls_buffers.c:601

gnutls.c: [2] ASSERT: ../../../src/gnutls-2.10.5/lib/gnutls_record.c:918

gnutls.c: [2] (Emacs) Deallocating x509 credentials
Mark saved where search started
xding
Quit

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message derived format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev nnheader mail-utils gmm-utils mailheader emacsbug
network-stream auth-source eieio byte-opt bytecomp byte-compile cconv
macroexp assoc gnus-util mm-util mail-prsvr password-cache starttls tls
gnutls advice advice-preload pager w3m-search w3m help-fns browse-url
doc-view easymenu jka-compr dired desktop regexp-opt image-mode timezone
w3m-hist w3m-fb bookmark-w3m w3m-ems w3m-ccl ccl w3m-favicon w3m-image
w3m-proc w3m-util wid-edit w3m-wget server easy-mmode cl edmacro kmacro
paren time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image
fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer button faces cus-face files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

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

From: martin rudalics <rudalics <at> gmx.at>
To: nyc4bos <at> aol.com
Cc: 10034 <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Sun, 13 Nov 2011 11:49:27 +0100

> Eventually, I would get into a state where I couldn't do much, seeing
> messages like:
>
> window-min-size-1: Variable binding depth exceeds max-specpdl-size
>
> I then could only kill Emacs.

Do you mean that Emacs looped and C-g didn't quit?  If you can see a
message like the above, C-g usually works.

> In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600)
>  of 2011-11-07 on MARVIN

IIUC this is with a build made _before_ Chong's `window-total-size'
change, so the latter can't be the culprit.

I can't propose much about this at the moment.  If this happens again
and you can get back to the command loop via C-g, try to open a new
frame via C-x 5 2 and look at the last lines of the *Messages* buffer.
If for some reason you can't make a new frame, try C-x 1 instead.

martin

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

From: nyc4bos <at> aol.com
To: martin rudalics <rudalics <at> gmx.at>
Cc: 10034 <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Sun, 13 Nov 2011 18:01:42 -0500

martin rudalics <rudalics <at> gmx.at> writes:

>> Eventually, I would get into a state where I couldn't do much, seeing
>> messages like:
>>
>> window-min-size-1: Variable binding depth exceeds max-specpdl-size
>>
>> I then could only kill Emacs.
>
> Do you mean that Emacs looped and C-g didn't quit?  If you can see a
> message like the above, C-g usually works.

C-g worked. However, other things that I did resulted in
"Variable binding depth exceeds max-specpdl-size" messages.

>
>> In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600)
>>  of 2011-11-07 on MARVIN
>
> IIUC this is with a build made _before_ Chong's `window-total-size'
> change, so the latter can't be the culprit.

I was using the "emacs-20111107-r106319-bin-i386.zip" Windows version.

>
> I can't propose much about this at the moment.  If this happens again
> and you can get back to the command loop via C-g, try to open a new
> frame via C-x 5 2 and look at the last lines of the *Messages* buffer.
> If for some reason you can't make a new frame, try C-x 1 instead.

The specific error message that I listed above:

  window-min-size-1: Variable binding depth exceeds max-specpdl-size

occurred when I tried to `C-SPC C-h M-w' the *Message* buffer.

When I was geting different "max-specpdl-size" errors with almost
everything I subsequently did, I started up a new Emacs instance in
order to file a bug report.

I then tried to copy the *Message* buffer from the original Emacs
instance that was having this problem into the new Emacs instance in
order to provide information for the bug report.

I could `C-x b' (switch-to-buffer) to the *Message* buffer and a few
other things but most things resulted in different "max-specpdl-size"
warning messages.

(BTW, I noticed that after sending a bug report and successfully
sending with `C-c C-c', the Bug Report Help buffer created when
invoking `(report-emacs-bug)' at least from the menu-bar, remains
visible as another (split) window.  Is that intentional?)

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

From: nyc4bos <at> aol.com
To: martin rudalics <rudalics <at> gmx.at>
Cc: 10034 <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Sun, 13 Nov 2011 20:24:49 -0500

martin rudalics <rudalics <at> gmx.at> writes:

Experimenting again, I got the following error messages:

Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size") [2 times]
xding
Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size")
image-search-load-path: Variable binding depth exceeds max-specpdl-sizeError during redisplay: (error "Variable binding depth exceeds max-specpdl-size")
Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size")
xding
Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size") [2 times]

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

From: martin rudalics <rudalics <at> gmx.at>
To: nyc4bos <at> aol.com
Cc: 10034 <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Mon, 14 Nov 2011 09:54:24 +0100

> C-g worked. However, other things that I did resulted in
> "Variable binding depth exceeds max-specpdl-size" messages.

In a situation like this does it help to do either

  C-x 5 2 to make a new frame and delete the old one, or

  C-x 1 to display only one window?

If either of this makes the messages disappear, the bug could be in the
window handling code.

> The specific error message that I listed above:
>
>   window-min-size-1: Variable binding depth exceeds max-specpdl-size
>
> occurred when I tried to `C-SPC C-h M-w' the *Message* buffer.

What is this key sequence supposed to do?

> When I was geting different "max-specpdl-size" errors with almost
> everything I subsequently did, I started up a new Emacs instance in
> order to file a bug report.
>
> I then tried to copy the *Message* buffer from the original Emacs
> instance that was having this problem into the new Emacs instance in
> order to provide information for the bug report.
>
> I could `C-x b' (switch-to-buffer) to the *Message* buffer and a few
> other things but most things resulted in different "max-specpdl-size"
> warning messages.

How many windows were on this Emacs frame at that time?

> (BTW, I noticed that after sending a bug report and successfully
> sending with `C-c C-c', the Bug Report Help buffer created when
> invoking `(report-emacs-bug)' at least from the menu-bar, remains
> visible as another (split) window.  Is that intentional?)

I don't know.  Looking at the code of `report-emacs-bug' I don't see a
call to remove a window but maybe I'm missing something.

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: nyc4bos <at> aol.com
Cc: 10034 <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Mon, 14 Nov 2011 09:54:30 +0100

> Experimenting again, I got the following error messages:
>
> Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size") [2 times]
> xding

What is xding?

> Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size")
> image-search-load-path: Variable binding depth exceeds max-specpdl-sizeError during redisplay: (error "Variable binding depth exceeds max-specpdl-size")

I can't see that image-search-load-path might run into an endless loop.

> Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size")
> xding
> Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size") [2 times]

Could be related to the image handling code.  Can you reproduce the error
in a session without loading images?

martin

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: nyc4bos <at> aol.com
Cc: 10034 <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Mon, 14 Nov 2011 09:08:41 -0500

> window-min-size-1: Variable binding depth exceeds max-specpdl-size

Please first try to:

  rm lisp/window.elc; make

just to make sure you're not seeing the recent "rebuild" problem.


        Stefan

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

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'martin rudalics'" <rudalics <at> gmx.at>, <nyc4bos <at> aol.com>
Cc: 10034 <at> debbugs.gnu.org
Subject: RE: bug#10034: 24.0.91; max-specpdl-size error
Date: Mon, 14 Nov 2011 06:38:19 -0800

> (BTW, I noticed that after sending a bug report and successfully
> sending with `C-c C-c', the Bug Report Help buffer created when
> invoking `(report-emacs-bug)' at least from the menu-bar, remains
> visible as another (split) window.  Is that intentional?)

Dunno whether it is related, but:

I have the bug-report window use a separate frame (special-display) - likewise,
the bug-report help buffer.  The help buffer's frame remains even after I've
sent the bug report.

That's something I can tolerate.  What's worse is that the frame used to show
the report buffer now iconifies (bad).  It used to disappear (be deleted) after
I hit C-c C-c to send the bug report.  This annoyance is new with Emacs 24.

There is obviously no reason to keep the report buffer (either of them,
actually) around in any visible way - e.g. as an icon.  After the dialog of
sending a bug report, these frames should be deleted.  If someone really wants
to revisit (display) the report buffer (but why?), well, that's what we have C-x
C-b and C-x b for.  Bad UI, IMHO.

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

From: nyc4bos <at> aol.com
To: martin rudalics <rudalics <at> gmx.at>
Cc: 10034 <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Tue, 15 Nov 2011 21:59:46 -0500

martin rudalics <rudalics <at> gmx.at> writes:

>> C-g worked. However, other things that I did resulted in
>> "Variable binding depth exceeds max-specpdl-size" messages.
>
> In a situation like this does it help to do either
>
>   C-x 5 2 to make a new frame and delete the old one, or
>
>   C-x 1 to display only one window?
>
> If either of this makes the messages disappear, the bug could be in the
> window handling code.

I haven't gotten the message message thus far with the new Emacs Windows
zip file released yesterday (emacs-20111114-r106380-bin-i386.zip) by
Christoph Scholtes with newer window.el/window.c code.

I'll keep trying for a litle while longer to see if I can reproduce
it.

>
>> The specific error message that I listed above:
>>
>>   window-min-size-1: Variable binding depth exceeds max-specpdl-size
>>
>> occurred when I tried to `C-SPC C-h M-w' the *Message* buffer.
>
> What is this key sequence supposed to do?

It sets the mark, (mark-whole-buffer), and (kill-ring-save) of the
*Message* buffer so that I could paste it in the new Emacs instance
to send my bug report.

>
>> When I was geting different "max-specpdl-size" errors with almost
>> everything I subsequently did, I started up a new Emacs instance in
>> order to file a bug report.
>>
>> I then tried to copy the *Message* buffer from the original Emacs
>> instance that was having this problem into the new Emacs instance in
>> order to provide information for the bug report.
>>
>> I could `C-x b' (switch-to-buffer) to the *Message* buffer and a few
>> other things but most things resulted in different "max-specpdl-size"
>> warning messages.
>
> How many windows were on this Emacs frame at that time?

Two.

>
>> (BTW, I noticed that after sending a bug report and successfully
>> sending with `C-c C-c', the Bug Report Help buffer created when
>> invoking `(report-emacs-bug)' at least from the menu-bar, remains
>> visible as another (split) window.  Is that intentional?)
>
> I don't know.  Looking at the code of `report-emacs-bug' I don't see a
> call to remove a window but maybe I'm missing something.
>
> martin

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

From: nyc4bos <at> aol.com
To: martin rudalics <rudalics <at> gmx.at>
Cc: 10034 <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Tue, 15 Nov 2011 22:14:15 -0500

martin rudalics <rudalics <at> gmx.at> writes:

>> Experimenting again, I got the following error messages:
>>
>> Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size") [2 times]
>> xding
>
> What is xding?

A "flashing" visible bell (ring-bell-function).

>
>> Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size")
>> image-search-load-path: Variable binding depth exceeds max-specpdl-sizeError during redisplay: (error "Variable binding depth exceeds max-specpdl-size")
>
> I can't see that image-search-load-path might run into an endless loop.
>
>> Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size")
>> xding
>> Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size") [2 times]
>
> Could be related to the image handling code.  Can you reproduce the error
> in a session without loading images?

The only image loaded was the splash screen, AFAICT.

>
> martin

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

From: nyc4bos <at> aol.com
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>, 10034 <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Tue, 15 Nov 2011 22:43:13 -0500

[I didn't receive Stefan's email but saw this on the mailing list.
Perhaps he only sent it there?]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> window-min-size-1: Variable binding depth exceeds max-specpdl-size
>
> Please first try to:
>
>  rm lisp/window.elc; make
>
> just to make sure you're not seeing the recent "rebuild" problem.

I'm using the pre-built Emacs Windows build and don't have the
make utilities on this machine.

Presumably, this will suffice:

    emacs -batch -f batch-byte-compile lisp/window.el

Dunno if it's related to a possible "rebuild" problem but I also got:

>> Error during redisplay: (error "Variable binding depth exceeds max-specpdl-size")
>> image-search-load-path: Variable binding depth exceeds max-specpdl-sizeError during redisplay: (error "Variable binding depth exceeds max-specpdl-size")


FYI:

Looking at timestamps on the .el/.elc files, I see:

11/07/2011  09:12 PM           231,600 window.el
11/07/2011  09:12 PM           197,385 window.elc

which I believe is the time that Christoph is compiling the .elc files
and then copying both .el and .elc to a ZIP archive.

Dunno for sure but I believe he is compiling .el files beforehand.

In any event, your suggestion to recompile the .elc file is prudent
and helps to rule out the "rebuild" problem.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: nyc4bos <at> aol.com
Cc: 10034 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Wed, 16 Nov 2011 06:01:58 +0200

> From: nyc4bos <at> aol.com
> Date: Tue, 15 Nov 2011 22:43:13 -0500
> Cc: 10034 <at> debbugs.gnu.org
> 
> > Please first try to:
> >
> >  rm lisp/window.elc; make
> >
> > just to make sure you're not seeing the recent "rebuild" problem.
> 
> I'm using the pre-built Emacs Windows build and don't have the
> make utilities on this machine.
> 
> Presumably, this will suffice:
> 
>     emacs -batch -f batch-byte-compile lisp/window.el

No, it will not.  window.elc is preloaded into the emacs.exe binary
you have.  If you recompile window.el as above, it will not be used,
unless you manually load it into Emacs:

  M-x load-library RET window RET

And then it will be used, but as soon as you restart Emacs, you will
have to reload it again, or be left with the old version.

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

From: nyc4bos <at> aol.com
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10034 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Sat, 19 Nov 2011 00:32:05 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: nyc4bos <at> aol.com
>> Date: Tue, 15 Nov 2011 22:43:13 -0500
>> Cc: 10034 <at> debbugs.gnu.org
>> 
>> > Please first try to:
>> >
>> >  rm lisp/window.elc; make
>> >
>> > just to make sure you're not seeing the recent "rebuild" problem.
>> 
>> I'm using the pre-built Emacs Windows build and don't have the
>> make utilities on this machine.
>> 
>> Presumably, this will suffice:
>> 
>>     emacs -batch -f batch-byte-compile lisp/window.el
>
> No, it will not.  window.elc is preloaded into the emacs.exe binary
> you have.  If you recompile window.el as above, it will not be used,
> unless you manually load it into Emacs:
>
>   M-x load-library RET window RET
>
> And then it will be used, but as soon as you restart Emacs, you will
> have to reload it again, or be left with the old version.

Thanks for the information.

I have a couple of questions about this:

1. Is there any way to determine that the .elc file that I have
   on-disk matches the preloaded .elc in the emacs.exe binary?

   Since I use the pre-built Emacs binary when on Windows, I presume
   that the .elc files I have on-disk were the ones loaded in the binary
   but I have no way of truely knowing unless I can query Emacs to tell
   me.

2. What are the preloaded .elc files?  Are they the ones from loadup.el?

   Can one ask the Emacs instance to compare the .elc file on-disk with
   the one that it was preloaded with to verify they are the same?

3. Can you startup Emacs to either ignore its (non-necessary) preloaded
   .elc files if the same file name (.el/.elc) resides on-disk or
   tell it to only use the files (.el/.elc) in the `load-path'
   and not what was preloaded?

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: nyc4bos <at> aol.com
Cc: 10034 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Sat, 19 Nov 2011 10:12:29 +0200

> From: nyc4bos <at> aol.com
> Cc: monnier <at> iro.umontreal.ca, 10034 <at> debbugs.gnu.org
> Date: Sat, 19 Nov 2011 00:32:05 -0500
> 
> 1. Is there any way to determine that the .elc file that I have
>    on-disk matches the preloaded .elc in the emacs.exe binary?

Why do you need to know?  In general, comparing the time stamps of the
.elc file with that of emacs.exe should be good enough.

>    Since I use the pre-built Emacs binary when on Windows, I presume
>    that the .elc files I have on-disk were the ones loaded in the binary

That's true.

> 2. What are the preloaded .elc files?  Are they the ones from loadup.el?

Yes.  But note that some of them are loaded based on conditions, so
not every `load' line in loadup.el is what ends up in emacs.exe.

>    Can one ask the Emacs instance to compare the .elc file on-disk with
>    the one that it was preloaded with to verify they are the same?

Once loaded, the .elc file is not kept as such in memory.  So you
cannot compare the file on disk with it.

> 3. Can you startup Emacs to either ignore its (non-necessary) preloaded
>    .elc files if the same file name (.el/.elc) resides on-disk or
>    tell it to only use the files (.el/.elc) in the `load-path'
>    and not what was preloaded?

No.

Message #49 received at 10034-quiet <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 10034-quiet <at> debbugs.gnu.org
Subject: Re: bug#10034: 24.0.91; max-specpdl-size error
Date: Tue, 27 Mar 2012 18:14:15 -0400

tags 10034 moreinfo,unreproducible
close 10034
stop

nyc4bos <at> aol.com wrote:

> I haven't gotten the message message thus far with the new Emacs Windows
> zip file released yesterday (emacs-20111114-r106380-bin-i386.zip) by
> Christoph Scholtes with newer window.el/window.c code.
>
> I'll keep trying for a litle while longer to see if I can reproduce it.

Previous Next

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