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 00:11:42 +0100
>> 
>> The corrupted loaddefs.el file seems to be the right size, but the last
>> 768 bytes are zero instead of the expected content.
>
> What is the total size of the loaddefs.el's text, in bytes?

For emacs-25 commit 24b87a1d4aadbdeafbc0db17e3a760cc9a7e21ef, the
corrupted loaddefs.el was 1192529 bytes, with the last 768 bytes zeroed.

Changing the files scanned for autoloads produces a loaddefs file of
different size (e.g. changed doc strings or different autoloads), and can
change the size of the zeroed portion at the end of the file.
 e.g. with local changes, 
    loaddefs.el 1192680 bytes, last 918 bytes zeroed
    loaddefs.el 1193247 bytes, last 918 bytes zeroed

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

>> Running that command using "bootstrap-emacs -Q" (i.e. interactively)
>> shows that the *autoload-file* buffer contains the 768 zero characters
>> at end, so it appears that the corruption occurs before the buffer is
>> written to disk.
>
> Yes, of course.  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.

>> Any hints on how to debug `batch-update-autoloads' to diagnose this
>> further would be welcome.
>
> The bug is unlikely to be on the Lisp level, it's something very deep
> in managing buffer memory.  Perhaps even on the level of mmap_alloc
> and mmap_realloc, as they are implemented in w32heap.c (since the only
> people who complain about this are building Emacs on Windows).
>
> If you can somehow establish where exactly in processing of the
> autoloads the corruption happens (i.e. what file is Emacs processing
> and what is the contents of the *autoload-file* buffer at that point),
> that would be a step forward, I think.

Any ideas to help do that are welcome. I've tried running the steps used
to build loaddefs.el from "bootstrap-emacs.exe -Q" and stepping though
it with edebug - that produces a working loaddefs.el :-(

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.

    AndyM