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 22:31:45 +0300

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

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

Theoretically, yes.  But not in practice, not in this case.

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

Thanks.



reply via email to

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