Re: Build failure for Emacs master

[Eli Zaretskii]

> From: Andy Moreton <address@hidden>
> 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.

> > 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.

> 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.

> 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?