emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Build failure for Emacs master


From: Eli Zaretskii
Subject: Re: Build failure for Emacs master
Date: Thu, 14 Apr 2016 20:48:43 +0300

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

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

> > 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'd start by establishing what Lisp file contributes the portion that
should be where you have nulls.

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

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]