[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 ¤t_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.
- Re: Build failure for Emacs master, (continued)
- Re: Build failure for Emacs master, Phillip Lord, 2016/04/20
- Re: Build failure for Emacs master, Eli Zaretskii, 2016/04/20
- Re: Build failure for Emacs master, Phillip Lord, 2016/04/20
- Re: Build failure for Emacs master, Eli Zaretskii, 2016/04/20
- Re: Build failure for Emacs master, Andy Moreton, 2016/04/20
- Re: Build failure for Emacs master, Phillip Lord, 2016/04/21
- Re: Build failure for Emacs master, Eli Zaretskii, 2016/04/14
- Re: Build failure for Emacs master, Andy Moreton, 2016/04/14
- Re: Build failure for Emacs master, Eli Zaretskii, 2016/04/14
- Re: Build failure for Emacs master, Andy Moreton, 2016/04/14
- Re: Build failure for Emacs master,
Eli Zaretskii <=
- Re: Build failure for Emacs master, Andy Moreton, 2016/04/14
- Re: Build failure for Emacs master, Eli Zaretskii, 2016/04/15
- Re: Build failure for Emacs master, Andy Moreton, 2016/04/15
- Re: Build failure for Emacs master, Eli Zaretskii, 2016/04/15
- Re: Build failure for Emacs master, Andy Moreton, 2016/04/15
- Re: Build failure for Emacs master, Angelo Graziosi, 2016/04/18
- Re: Build failure for Emacs master, Eli Zaretskii, 2016/04/18
- Re: Build failure for Emacs master, Andy Moreton, 2016/04/18
- Re: Build failure for Emacs master, Angelo Graziosi, 2016/04/19
- Re: Build failure for Emacs master, Eli Zaretskii, 2016/04/19