Re: Build failure for Emacs master

[Andy Moreton <andrewjmoreton@gmail.com>]

On Fri 15 Apr 2016, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Thu, 14 Apr 2016 21:30:19 +0100
>> 
>> >> (gdb) p/x &current_buffer->text->beg[0]
>> >> $4 = 0x65a0000
>> >> (gdb) find /b9 current_buffer->text->beg,current_buffer->text->beg+GPT_BYTE-1,0
>> >> 0x66c36b4
>> >> 1 pattern found.
>> >
>> > That's not the nulls you reported.  What is the value of GPT_BYTE at
>> > this point, and what is the value of Z_BYTE?
>> 
>> It's not the same binary - efforts to detect what causes the corruption
>> necessitate rebuilding. 
>
> You said you can reproduce this at will, so I thought doing that is
> not a problem, and then the values would be the same as in this run.
> Apologies if I misunderstood.

I can reproduce this repeatably from running make, or after building
bootstrap-emacs.exe using just the command line used to update
loadddefs.el.

Attempts to debug with bootstrap-emacs -Q and evaluating the equivalent
commands in the scratch buffer (or loaded from a file) do not show the
problem. Running under gdb gives variable results.

>> > Sorry, I'm still confused: are the nulls coming from a previous
>> > loaddefs.el, or are they coming from Emacs?  If the latter, is it true
>> > that to reproduce the problem, you need to start from a clean tree,
>> > but use an outdated version of ldefs-boot.el?
>> 
>> As I understand it, building from a clean tree:
>>  a) temacs.exe is built (a bare emacs)
>>  b) bootstrap-emacs.exe is built from temacs.exe, using ldefs-boot.el
>
> The last part is only true if there's no loaddefs.el file in the
> tree.  See the commentary and the relevant code in loadup.el.  If
> loaddefs.el does exist, bootstrap-emacs build will use it.

Noted, but here I am building from a clean tree so that loaddefs.el does
not exist.

>> As one of my experiments produced a good loaddefs.el, I did this:
>>  - start from a completely clean emacs-25 tree
>>  - overwrite ldefs-boot.el with the previously built loaddefs.el
>>  - do a full bootstrap, which succeeded.
>
> What are the differences between that "successful" loaddefs.el and
> ldefs-boot.el which produces a corrupted loaddefs.el?  The only
> changes I see are in the time stamp cookies.

The changes I see are:
 - timestamp changes
 - changed autoloads from your changes to grep.el
 - changes to the files listed in the comment at the end.

--[diff ldefs-boot.el loaddefs.el]------------------------------------
@@ -12876,16 +12829,22 @@
 The default grep program for `grep-command' and `grep-find-command'.
 This variable's value takes effect when `grep-compute-defaults' is called.")
 
-(defvar find-program (purecopy "find") "\
+(custom-autoload 'grep-program "grep" t)
+
+(defvar grep-find-program (purecopy "find") "\
 The default find program.
 This is used by commands like `grep-find-command', `find-dired'
 and others.")
 
-(defvar xargs-program (purecopy "xargs") "\
+(custom-autoload 'grep-find-program "grep" t)
+
+(defvar grep-xargs-program (purecopy "xargs") "\
 The default xargs program for `grep-find-command'.
 See `grep-find-use-xargs'.
 This variable's value takes effect when `grep-compute-defaults' is called.")
 
+(custom-autoload 'grep-xargs-program "grep" t)
+
 (defvar grep-find-use-xargs nil "\
 How to invoke find and grep.
 If `exec', use `find -exec {} ;'.
--[diff ldefs-boot.el loaddefs.el]------------------------------------

Should the define-obsolete-variable-alias forms for find-program and
xargs-program be marked as autoloads ?

>> I do not know if replacing ldefs-boot.el with a freshly built loaddefs.el
>> fixed the problem, or simply moved the timing around enough that this
>> Heisenbug no longer occurred.
>
> Sorry, I don't understand: what timing could change as result of
> modifying one of the inputs?  Are you saying that the differences (in
> size or content) are so significant s to affect the time to read the
> file into memory?

No, but changing the content of ldefs-boot.el can change the timing and
behaviour of the bootstrap-emacs.exe that is built from it. Whether the
observed bug is timing related or completely deterministic is not yet
known.

    AndyM