From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Build failure for Emacs master Date: Thu, 14 Apr 2016 22:31:45 +0300 Message-ID: <83fuuodm1q.fsf@gnu.org> References: <56CCD91E.6070507@alice.it> <83egc2ixji.fsf@gnu.org> <56CD798D.7060102@alice.it> <56CD8408.1000701@alice.it> <83wppuggb4.fsf@gnu.org> <56CE2CA7.5050906@alice.it> <83io1cg2pt.fsf@gnu.org> <56DA0327.2030009@alice.it> <83oaatxu72.fsf@gnu.org> <570C4307.6050907@alice.it> <83k2k2g82s.fsf@gnu.org> <86egaa7b0z.fsf@gmail.com> <83a8kyfd38.fsf@gnu.org> <86lh4hm7dd.fsf@gmail.com> <83oa9cdu7l.fsf@gnu.org> <83k2k0dqtg.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1460662359 31325 80.91.229.3 (14 Apr 2016 19:32:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2016 19:32:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 14 21:32:29 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aqn05-0000gV-H4 for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 21:32:25 +0200 Original-Received: from localhost ([::1]:45342 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqn04-0002s4-Oq for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 15:32:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqmzs-0002pS-Hv for emacs-devel@gnu.org; Thu, 14 Apr 2016 15:32:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqmzp-0008L3-D4 for emacs-devel@gnu.org; Thu, 14 Apr 2016 15:32:12 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqmzp-0008Kz-AR; Thu, 14 Apr 2016 15:32:09 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1275 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aqmzo-0006Y8-Kx; Thu, 14 Apr 2016 15:32:09 -0400 In-reply-to: (message from Andy Moreton on Thu, 14 Apr 2016 19:40:47 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:202930 Archived-At: > From: Andy Moreton > 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.