GNU bug report logs - #78898
Make read/readevalloop reentrant

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: Lynn Winebarger <owinebar <at> gmail.com>
Cc: 78898 <at> debbugs.gnu.org
Subject: bug#78898: Make read/readevalloop reentrant
Date: Fri, 27 Jun 2025 09:19:59 +0000

"Lynn Winebarger" <owinebar <at> gmail.com> writes:

> I tried explicitly forcing emacs-internal as the coding-system for
> load_source_file, but without any noticeable difference.

Hmm.  I think the problem there is that you specbind
Qcoding_system_for_read to Qemacs_internal while calling
dump-emacs-portable.  The pdumper doesn't unwind specbind bindings, so
the Vcoding_system_for_read variable is dumped with that value, and
restored with that value from the dump, and then things go wrong because
other code assumes Vcoding_system_for_read is non-nil.

> The button preceding the warning messages should be a stop sign emoji.
> Using the built emacs to view emacs-lisp/warning.el shows the stop
> sign emoji clearly, but it is apparently mangled in the generated
> byte-code in warning.elc.

To me, it looks like it's encoded in warnings.elc as a UTF-8 sequence.
But you force coding_system_for_read to emacs-internal, so it's read as
garbage.  The same problem, by the way, applies to ja-dic-cnv.el, which
contains verbatim UTF-8 data which is then copied into ja-dic-cnv.elc
and misread.




> I also built a clean emacs from commit
> 2bdcf0250acecdb0719203ae711aedf5baad1783.  When I compared the source
> elisp files (after building) I see differences in these files:
> lisp/international/uni-bidi.el
> lisp/international/uni-brackets.el
> lisp/international/uni-category.el
> lisp/international/uni-combining.el
> lisp/international/uni-comment.el
> lisp/international/uni-decomposition.el
> lisp/international/uni-old-name.el
> lisp/international/uni-name.el
> lisp/leim/leim-list.el
> lisp/leim/ja-dic/ja-dic.el
> lisp/net/tramp-loaddefs.el
> lisp/textmodes/reftex-loaddefs.el
> lisp/loaddefs.el
> lisp/finder-inf.el
> lisp/cus-load.el
>
> In the byte-compiled files, I see differences for:
> lisp/emacs-lisp/eieio-opt.elc
> lisp/erc/erc-nicks.elc
> lisp/erc/erc.elc
> lisp/eshell/em-cmpl.elc
> lisp/gnus/gnus-group.elc
> lisp/gnus/gnus-srvr.elc
> lisp/gnus/gnus-topic.elc
> lisp/gnus/gnus-sieve.elc
> lisp/gnus/gnus-search.elc
> lisp/gnus/message.elc
> lisp/gnus/nnfeed.elc
> lisp/gnus/nnml.elc
> lisp/gnus/nnimap.elc
> lisp/gnus/nnagent.elc
> lisp/gnus/nnmaildir.elc
> lisp/gnus/gnus-start.elc
> lisp/gnus/gnus-sum.elc
> lisp/gnus/nnmairix.elc
> lisp/gnus/nnselect.elc
> lisp/net/tramp-cache.elc
> lisp/net/tramp-cmds.elc
> lisp/net/tramp-gvfs.elc
> lisp/net/tramp-sh.elc
> lisp/obsolete/nnir.elc
> lisp/org/org-agenda.elc
> lisp/org/org-lint.elc
> lisp/org/ox-ascii.elc
> lisp/org/ox-odt.elc
> lisp/org/org.elc
> lisp/progmodes/eglot.elc
> lisp/progmodes/cc-engine.elc
> lisp/progmodes/cc-mode.elc
> lisp/progmodes/js.elc
> lisp/use-package/use-package-core.elc
> lisp/loaddefs.elc
>
> I'm not clear on why loaddefs.el should be different.  That, and
> eieio-opt.elc being different is unexpected.

Did you use a parallel build?  As our defsubst expansion is
unpredictable in parallel builds, there may be bytecode differences that
will simply go away if you rebuild (bootstrap) without the "-j" flag.  I
suspect that's what happened here, since I don't see a difference in
that file.


>
> Lynn
>
> [2. text/x-patch; 0002-Try-explicit-use-of-emacs-internal-coding-in-load_so.patch]...

Previous Next

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