GNU bug report logs - #43116
27.1; with-eval-after-load executes BODY multiple times for fortran

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 43116 in the body.
You can then email your comments to 43116 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: Nonax <nonax <at> posteo.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; with-eval-after-load executes BODY multiple times for fortran
Date: Sun, 30 Aug 2020 18:18:51 +0200

Hello,

The following command will reproduce the bug: emacs -Q -l mwe.el f.f

f.f does not have to exist, it just serves to open a buffer and enable
fortran-mode.  The file mwe.el contains the following:

(with-eval-after-load 'fortran
  (if (boundp 'fortran-canary)
      (message "..is cursed.")
    (message "FORTRAN.."))
  (defvar fortran-canary t))
;;; end of mwe.el

The following message will appear in the *Message* buffer:
FORTRAN..
..is cursed.

suggesting BODY has been executed twice.  This problem seems to persist
across multiple versions of Emacs.  It seems to only apply to fortran
specifically, however.  I could not reproduce it with other features.

Kind regards,
N.

In GNU Emacs 27.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
3.24.21, cairo version 1.16.0)
 of 2020-08-20 built on buildvm-x86-24.iad2.fedoraproject.org
Windowing system distributor 'Fedora Project', version 11.0.12008000
System Description: Fedora 32 (Workstation Edition)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
(New file)
FORTRAN..
..is cursed.
Making completion list... [2 times]

Configured using:
 'configure --build=x86_64-redhat-linux-gnu
 --host=x86_64-redhat-linux-gnu --program-prefix=
 --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
 --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
 --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
 --libexecdir=/usr/libexec --localstatedir=/var
 --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules --with-harfbuzz
 --with-cairo --with-json build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
 -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS
LIBSYSTEMD JSON PDUMPER GMP

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fortran

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-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

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils fortran cus-edit
easymenu cus-start cus-load wid-edit cl-loaddefs cl-lib tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting xwidget-internal cairo move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 66282 11790)
 (symbols 48 7807 1)
 (strings 32 19871 1395)
 (string-bytes 1 608771)
 (vectors 16 11410)
 (vector-slots 8 142908 11478)
 (floats 8 28 41)
 (intervals 56 263 0)
 (buffers 1000 14))

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

From: Alan Mackenzie <acm <at> muc.de>
To: Nonax <nonax <at> posteo.net>
Cc: acm <at> muc.de, 43116 <at> debbugs.gnu.org
Subject: Re: bug#43116: 27.1;
 with-eval-after-load executes BODY multiple times for fortran
Date: 31 Aug 2020 11:34:28 -0000

Hello, Nonax.

In article <mailman.1792.1598806565.2469.bug-gnu-emacs <at> gnu.org> you wrote:
> Hello,

> The following command will reproduce the bug: emacs -Q -l mwe.el f.f

> f.f does not have to exist, it just serves to open a buffer and enable
> fortran-mode.  The file mwe.el contains the following:

> (with-eval-after-load 'fortran
>   (if (boundp 'fortran-canary)
>       (message "..is cursed.")
>     (message "FORTRAN.."))
>   (defvar fortran-canary t))
> ;;; end of mwe.el

> The following message will appear in the *Message* buffer:
> FORTRAN..
> ..is cursed.

> suggesting BODY has been executed twice.  This problem seems to persist
> across multiple versions of Emacs.  It seems to only apply to fortran
> specifically, however.  I could not reproduce it with other features.

> Kind regards,
> N.

> In GNU Emacs 27.1 (build 1, x86_64-redhat-linux-gnu, GTK+ Version
> 3.24.21, cairo version 1.16.0)
>  of 2020-08-20 built on buildvm-x86-24.iad2.fedoraproject.org
> Windowing system distributor 'Fedora Project', version 11.0.12008000
> System Description: Fedora 32 (Workstation Edition)

[ .... ]

Diagnosis:

1. At a fairly low level, (load "fortran") gets called.
2. In fortran.el L658 in (defvar fortran-mode-map ....) there's a form
  ,(custom-menu-create 'fortran).  This gets evaluated during the load.
3. custom-menu-create's call stack (pertinent part) looks like:
   (do-after-load-evaluation "path/to/fortran.elc")
   (require 'fortran)         <=========================================
   (custom-load-symbol 'fortran)
   (custom-menu-create 'fortran)
4. The above do-after-load-evaluation eventually calls the fortran
   eval-after-load function that outputs "FORTRAN..".
5. At a later stage of the load, do-after-load-evaluation gets called by
   load normally.  This calls the eval-after-load function again, which
   outputs "..is cursed.".

In a nutshell, the problem is the recursive (require 'fortran) called
from within (load "fortran").

I don't yet have any idea on how to fix this bug.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

From: Nonax <nonax <at> posteo.net>
To: Alan Mackenzie <acm <at> muc.de>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 43116 <at> debbugs.gnu.org, emacs-devel <at> gnu.org
Subject: Re: Recursive Fload and eval-after-load forms. (See bug #43116.)
Date: Mon, 31 Aug 2020 22:27:36 +0200

Hi all,

I looked into a matter a bit and, while I don't have a solution myself,
noticed something very strange.  You made me aware of the fact that the
fortran modes (both fortran-mode and f90) use custom-menu-create
directly.  The thing I find exceptional about that is that absolutely no
other major mode uses this function this way, period.  A quick grep
shows that the only other file in the lisp/ directory using it is
eudc.el, and it uses it to bind the return value to a const.

So it seems that it does a rather standard thing (setting up a menu for
a major mode) in a very exceptional way.  I am still quite new to
writing modes, but I guess one could circumvent the direct usage of
custom-menu-create entirely.

I've also been poking around some more to see what modules use it
indirectly, to see how they deal with potential issues.  The function is
used by two more functions in cus-edit: custom-group-menu-create (unused
in the entire lisp/ subdir) and customize-menu-create, which is used by
cus-edit itself once to create Custom-mode-menu.  Almost all other
modules using customize-menu-create (org.el, idlwave.el, reftex.el)
define a function <mode>-create-customize-menu which calls it in return.
 The only other module using it differently is wid-browse.el, which uses
it in a similar way cus-edit itself uses it.

So all in all the hierarchy of files using custom-menu-create at all is
quite small, and it seems the majority does not actually call it at
evaluation time, but instead have it called as a function bound to a
menu point (meaning it will be called upon user input when everything
important already happened).

I would have to do a lot more digging to really get what
custom-menu-create and family really do, but I get the feeling that
fortran-mode kind of (ab)uses it in a way that was not originally
anticipated.  I hope this information proves somewhat useful, but my
pattern recognition tells me it does.

Cheers,
Nonax

On 31/08/2020 20:45, Alan Mackenzie wrote:
> Hello, Emacs.
> 
> In bug #43116, the OP has rightly complained that on loading
> fortran.elc, his eval-after-load forms get evaluated twice.
> 
> The cause of the double evaluation is a custom-menu-create form in
> fortran.el, which causes a recursive evaluation of (load "fortran").
> The eval-after-load-forms are evaluated both for the "inner" load and
> the "outer" load.
> 
> What do people think of the following proposal: that the eval-after-load
> forms should be evaluated only after the outermost load has completed?
> This would be a simple amendment to the function Fload.
> 

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nonax <nonax <at> posteo.net>
Cc: 43116 <at> debbugs.gnu.org
Subject: Re: bug#43116: 27.1; with-eval-after-load executes BODY multiple
 times for fortran
Date: Sat, 12 Jun 2021 14:46:20 +0200

Nonax <nonax <at> posteo.net> writes:

> The following command will reproduce the bug: emacs -Q -l mwe.el f.f
>
> f.f does not have to exist, it just serves to open a buffer and enable
> fortran-mode.  The file mwe.el contains the following:
>
> (with-eval-after-load 'fortran
>   (if (boundp 'fortran-canary)
>       (message "..is cursed.")
>     (message "FORTRAN.."))
>   (defvar fortran-canary t))
> ;;; end of mwe.el
>
> The following message will appear in the *Message* buffer:
> FORTRAN..
> ..is cursed.
>
> suggesting BODY has been executed twice. 

Yup -- you and Alan diagnosed the problem (a recursive load in the
easymenu call), and I think the easiest fix here is just to do define
the menu at the end of fortran.el.  So I've now done this in Emacs 28.

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

Previous Next

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