erroneous byte-compilation during build process?

erroneous byte-compilation during build process?

[Stephen Berman]

I'm running GNU Emacs 22.0.50.14 (i686-pc-linux-gnu, GTK+ Version
2.8.10) of 2006-04-17.  I think this build produced an erroneous
byte-compiled file.  As usual, I built Emacs after cvs up following
the recommendation in INSTALL.CVS:

$ ./configure --with-x-toolkit=gtk
$ make
$ cd lisp
$ make recompile EMACS=../src/emacs
$ cd ..
$ su
# make install

With my current build, I have had no reproducible crashes or other
serious problems, except that I have occasionally gotten a strange
error while using recentf-mode (if I'm right below, the particulars of
the error are, at least for now, irrelevant).  The error doesn't
usually arise when I use recentf-mode, so I had ignored it till
recently.  But the last time I got the error in ordinary use, I decide
to try to debug it.  I determined that it happens only under certain
conditions, and I traced it to a certain lisp function call, but the
strange thing is, when stepping through with edebug, the error failed
to arise.  Because of this, it occurred to me that the error might not
be in recentf.el but in recentf.elc.  So I made a fresh
byte-compilation of the source file and copied it to the install
directory and loaded recentf, making sure the conditions that give
rise to error were satisfied, and sure enough, the error failed to
occur.  Then I reinstalled the original byte-compiled file and
repeated the test, and got the error again.  So I conclude that the
recentf.elc made by building Emacs is somehow erroneous.

Is my conclusion plausible?  If so, is it cause for concern that there
may be other erroneous byte-compiled files in the installation tree?
And does this indicate a bug in the byte compiler, or could something
else induce the error?  The two recentf.elc files -- the one made by
the build process and the one I byte-compiled from source -- differ in
almost every line, as shown by diff -a, but I don't know what the
differences mean: as far as I can tell, they only differ in cons cells
like this:

19c19
< (defvar recentf-list nil (#$ . 677))
---
> (defvar recentf-list nil (#$ . 671))

I also disassembled the function where the error occurs, once with the
original recentf.elc installed and once with the new byte-compilation
I made, but the outputs were identical.  Does this make sense?  Is
there a way to check the correctness of a byte-compilation of a source
file?

Steve Berman

Re: erroneous byte-compilation during build process?

[Stuart D. Herring]

> Is my conclusion plausible?  If so, is it cause for concern that there
> may be other erroneous byte-compiled files in the installation tree?
> And does this indicate a bug in the byte compiler, or could something
> else induce the error?  The two recentf.elc files -- the one made by
> the build process and the one I byte-compiled from source -- differ in
> almost every line, as shown by diff -a, but I don't know what the
> differences mean: as far as I can tell, they only differ in cons cells
> like this:
>
> 19c19
> < (defvar recentf-list nil (#$ . 677))
> ---
> > (defvar recentf-list nil (#$ . 671))

If these are the only changes, they're entirely irrelevant; the numbers
just indicate the places in the file where the documentation can be found.
 The difference is probably a difference in the length of the file name
given in the comment block at the top.  Check for other differences, or
make the file/path names the same length for testing.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: erroneous byte-compilation during build process?

[Stephen Berman]

On Tue, 2 May 2006 12:46:47 -0700 (PDT) "Stuart D. Herring"
<herring@lanl.gov> wrote: 

>> The two recentf.elc files -- the one made by the build process and
>> the one I byte-compiled from source -- differ in almost every line,
>> as shown by diff -a, but I don't know what the differences mean: as
>> far as I can tell, they only differ in cons cells like this:
>>
>> 19c19
>> < (defvar recentf-list nil (#$ . 677))
>> ---
>> > (defvar recentf-list nil (#$ . 671))
>
> If these are the only changes, they're entirely irrelevant; the numbers
> just indicate the places in the file where the documentation can be found.
>  The difference is probably a difference in the length of the file name
> given in the comment block at the top.  Check for other differences, or
> make the file/path names the same length for testing.

Thanks for the pointer.  Now the diff -a output is much smaller, and
it was easy to spot the differences; in fact, the very first diff of
byte-compiled functions is the function where the error arises:

2c2
< ;;; Compiled by steve@escher.local.home on Sun Apr 16 17:30:57 2006
---
> ;;; Compiled by steve@escher.local.home on Tue May  2 23:06:58 2006
426c426
< (defalias 'recentf-open-files #[(&optional files buffer-name) "\b\204\f\0	\204\f\0\306\307!\210r\310\n\206\x16\0\311\312\v\"!q\210\313\314 \x1c\x1d\315\316\f@\"\210\315\316\fA\"\210\317 \210*\320 \210\321\322\x0e.\203<\0\323\202=\0\324\325\326$\210\327\211\x1e/\x0e\x1a\205N\0\x0e\x1a\330H\230\204b\0\331\332!\210\333\334\335\"\211\x16\x1a\330\x0e/I\210)\336\337\340\341\342\343\344\345\b\206p\0	!BBBBB\"\210\337\346\347\350\351$\210\352\353!\210\354 \210\355p!)\207" [files recentf-list buffer-name recentf-menu-title ol inhibit-read-only error "There is no recent file to open" get-buffer-create format "*%s*" t overlay-lists mapc delete-overlay erase-buffer recentf-dialog-mode widget-insert "Click on a file" ", or type the corresponding digit key," "" " to open it.\n" "Click on Cancel or type `q' to cancel.\n" "folder" 0 make-local-variable tree-widget--theme make-vector 4 nil apply widget-create group :indent 2 :format "\n%v\n" recentf-open-files-items push-button :notify recentf-cancel-dialog "Cancel" recentf-dialog-goto-first link widget-setup switch-to-buffer recentf-show-file-shortcuts-flag name] 10 (#$ . 43202) nil])
---
> (defalias 'recentf-open-files #[(&optional files buffer-name) "\b\204\f\0	\204\f\0\306\307!\210r\310\n\206\x16\0\311\312\v\"!q\210\313\314 \x1c\x1d\315\316\f@\"\210\315\316\fA\"\210\317 \210*\320 \210\321\322\x0e)\203<\0\323\202=\0\324\325\326$\210\327\330!\210\331\332\333\334\335\336\337\340\b\206R\0	!BBBBB\"\210\332\341\342\343\344$\210\345\346!\210\347 \210\350p!)\207" [files recentf-list buffer-name recentf-menu-title ol inhibit-read-only error "There is no recent file to open" get-buffer-create format "*%s*" t overlay-lists mapc delete-overlay erase-buffer recentf-dialog-mode widget-insert "Click on a file" ", or type the corresponding digit key," "" " to open it.\n" "Click on Cancel or type `q' to cancel.\n" tree-widget-set-theme "folder" apply widget-create group :indent 2 :format "\n%v\n" recentf-open-files-items push-button :notify recentf-cancel-dialog "Cancel" recentf-dialog-goto-first link widget-setup switch-to-buffer recentf-show-file-shortcuts-flag] 9 (#$ . 43202) nil])

These differ only in the last few hundred characters, specifically
here:

< "folder" 0 make-local-variable tree-widget--theme make-vector 4 nil
---
> tree-widget-set-theme "folder"

and here:

< recentf-show-file-shortcuts-flag name] 10
---
> recentf-show-file-shortcuts-flag] 9

(Subsequent differences in the diff -a output are only in the
documentation cons cells, evidently due to the differing lengths of
the above pieces of byte compiled code.)  In fact, the first
difference shows the reason for error I was getting (a missing call to
tree-widget-set-theme).  So this seems to prove that the original
byte-compilation of recentf.el, produced by the build process, is
erroneous.  The question remains, how did this happen?  Why did the
Emacs build process yield an erroneous byte compilation, while my byte
compilation of the same source yielded a correct one?

Steve Berman

Re: erroneous byte-compilation during build process?

[Richard Stallman]

I am going through messages which I failed to handle during the past
year, and came across yours.

      Because of this, it occurred to me that the error might not
    be in recentf.el but in recentf.elc.  So I made a fresh
    byte-compilation of the source file and copied it to the install
    directory and loaded recentf, making sure the conditions that give
    rise to error were satisfied, and sure enough, the error failed to
    occur.  Then I reinstalled the original byte-compiled file and
    repeated the test, and got the error again.  So I conclude that the
    recentf.elc made by building Emacs is somehow erroneous.

Does this still happen?  Can you make it happen?  Did we ever make a
change that should have fixed it?

It is clear that there was a miscompilation.  There's a difference in
the bytecode of the two versions of the function recentf-open-files,
as well as in the arguments.  I think that the function 
tree-widget-set-theme got open coded in one of the two versions
but was called with a function call in the other.