Re: Skipping unexec via a big .elc file

[Ken Raeburn]

I think I may have figured out why I was getting crashes relating to the face 
cache but it wasn’t very reproducible.  Some of the face creation code paths 
will ensure that a cache exists for a frame before using it — like the handling 
of “menu” in internal-set-lisp-face-attribute — and some do not.  In a regular 
Emacs build, the order of operations in the C and Lisp code dictate the order 
in which face definitions are processed.  So, for example, in a batch-mode test 
invocation I tried, the “menu” face handling created the cache for frame “F1” 
before using it.

But using dumped.elc, face property settings get restored, but the code 
generated assumes that the order doesn’t matter, so the list of face names 
depends not just on which Lisp code was loaded, but on the order they’re seen 
under “mapatoms”, i.e., based on load order and the obarray size.  (So my 
Mac/NS and GNU/Linux/X11 builds have different lists of names, and different 
orders.)

I’m looking at internal-set-lisp-face-attribute as a place to always ensure the 
existence of the cache, but there may be a better location.

On Jan 14, 2017, at 05:41, Eli Zaretskii <address@hidden> wrote:
> [… much about failures I’m still looking at…]
> One other thing I noticed is that most of the *.elc files produced by
> this build are different from those I see on master.  The differences
> are sometimes just a few bytes (e.g., in mule-diag.elc), but sometimes
> much larger (e.g., files.elc).  Perhaps this points to some subtle
> problem in byte compilation?  But even if so, that cannot explain the
> failure to compile eww.el and ja-dic.el.

I built a couple versions, and found several .elc files different.  The first 
case I looked at was macroexp--const-symbol-p in macroexp.elc.  From 
disassembling, it appears that the expression “(boundp 
'byte-compile-const-variables)” is optimized out in the build from the branch 
point, but not in the build including the dumped.elc changes.  I’m not sure why 
yet, but it’s almost certainly a bug that they’re different.  And a bug 
affecting the emacs-lisp environment and/or the byte compiler output could 
certainly cause later attempts at byte compilation (using newly byte-compiled 
code) to misbehave.

Ken