Re: Build failure for Emacs master

[Andy Moreton]

On Thu 14 Apr 2016, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> Date: Thu, 14 Apr 2016 19:40:47 +0100
>> 
>> Thread 1 hit Breakpoint 1, Fwrite_region (start=..., end=..., filename=...,
>> append=..., visit=..., lockname=..., mustbenew=...) at
>> ../../src/fileio.c:4678
>> 4678   return write_region (start, end, filename, append, visit, lockname, 
>> mustbenew,
>> (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. 

>> > Are you saying that loaddefs.el is corrupted because the previous
>> > loaddefs.el was already corrupted?  If so, the corruption is not
>> > really reproducible, is it?  What happens if you manually correct
>> > loaddefs.el (e.g., by bringing a copy from another build), and then
>> > try building without "git clean"?
>> 
>> The whole purpose of starting from a clean tree is to ensure that there
>> is no interference from a previous failed build. batch-update-autoloads
>> updates loaddefs.el in place if that file already exists, so if a
>> previous build has left a corrupted version then subsequent builds will
>> fail.
>> 
>> My point was that replacing ldefs-boot.el with an up to date copy of
>> loaddefs.el stopped the corruption. The bootstrap-emacs.exe built using
>> the udpated ldefs-boot.exe produced a working loaddefs.el.
>
> 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
 c) bootstrap-emacs.exe is used to create or update loaddefs.el
 d) emacs.exe is built using loaddefs.el

If (c) fails leaving a corrupted loaddefs.el file, then any following
build will also fail. This means that trying to dettermine what causes
the corruption requires that loaddefs.el is deleted before each attempt.

The zero bytes seen in this problem come from step (c). If similar
commands are run using "bootstrap-emacs -Q" then when the corruption
occurs, the zero bytes are visible in the emacs buffer.

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.

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.

    AndyM