Re: Build failure for Emacs master

[Andy Moreton <andrewjmoreton@gmail.com>]

On Thu 14 Apr 2016, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Thu, 14 Apr 2016 18:06:02 +0100
>> 
>> > Also, can you look in GDB at the buffer text, before it is written to
>> > disk, and tell how far, in bytes, is the first null from the beginning
>> > of buffer text?  (Let me know if you need advice for how to do that
>> > with GDB commands.)
>> 
>> Please give precise instructions as I have no idea how to do that.
>
> Put  breakpoint in Fwrite_region, and when it breaks, type these
> commands:
>
>  (gdb) p/x &current_buffer->text->beg[0]
>  (gdb) find /b9 current_buffer->text->beg,current_buffer->text->beg+GPT_BYTE-1,0
>
> The first one should display the address of the beginning of buffer
> text.  The second one should display up to 9 places where there are
> nulls in the buffer, I expect them to be consecutive addresses.  The
> first one of those is the address I'm looking for.

Starting from a tree without a loaddefs.el file, the breakpoint is hit
twice. The first time is when the skeleton loaddefs.el is written, that
contains just the comemnt header and the trailer with the local
variable settings. The second time is when it writes the completed
autoloads buffer:

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.
(gdb) 

>> > The corruption is caused by inserting and deleting text into/from
>> > the buffer, as part as producing the autoload forms.
>> 
>> That wasn't at all obvious to me without some testing: it could easily
>> have been caused by problems serialising the buffer to disk.
>
> There's no serializing, buffer text is (almost) a linear array of
> bytes.  (Or do you mean encoding?)

I meant any of the processing to get from content in memory to bits on
spinning rust. That can include marshalling, encoding, flushing buffers
etc. (not all of which apply here).

>> If I start from a completely clean tree (after "git clean -Xdf") and
>> then copy the working loaddefs.el (produced above) to ldefs-boot.el,
>> then a full bootstrap succeeds, and the resulting loaddefs.el is good.
>
> 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.

    AndyM