From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: Build failure for Emacs master Date: Thu, 14 Apr 2016 21:30:19 +0100 Message-ID: <864mb4j5lw.fsf@gmail.com> 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> <83fuuodm1q.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1460665880 23070 80.91.229.3 (14 Apr 2016 20:31:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2016 20:31:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 14 22:31:13 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 1aqnuy-0005jv-IE for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 22:31:12 +0200 Original-Received: from localhost ([::1]:46243 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqnux-0006rt-QT for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2016 16:31:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqnuh-0006pH-Hp for emacs-devel@gnu.org; Thu, 14 Apr 2016 16:30:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqnuc-0000Zl-9w for emacs-devel@gnu.org; Thu, 14 Apr 2016 16:30:55 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:46761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqnuc-0000Zg-2r for emacs-devel@gnu.org; Thu, 14 Apr 2016 16:30:50 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aqnub-0005X0-3S for emacs-devel@gnu.org; Thu, 14 Apr 2016 22:30:49 +0200 Original-Received: from 82-69-64-228.dsl.in-addr.zen.co.uk ([82.69.64.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2016 22:30:49 +0200 Original-Received: from andrewjmoreton by 82-69-64-228.dsl.in-addr.zen.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Apr 2016 22:30:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 67 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82-69-64-228.dsl.in-addr.zen.co.uk User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (windows-nt) Cancel-Lock: sha1:bOyrERFawghfZu03tGD2XfMDu/s= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:202935 Archived-At: On Thu 14 Apr 2016, Eli Zaretskii wrote: >> 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? It's not the same binary - efforts to detect what causes the corruption necessitate rebuilding. >> > 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? As I understand it, building from a clean tree: a) temacs.exe is built (a bare emacs) b) bootstrap-emacs.exe is built from temacs.exe, using ldefs-boot.el c) bootstrap-emacs.exe is used to create or update loaddefs.el d) emacs.exe is built using loaddefs.el If (c) fails leaving a corrupted loaddefs.el file, then any following build will also fail. This means that trying to dettermine what causes the corruption requires that loaddefs.el is deleted before each attempt. The zero bytes seen in this problem come from step (c). If similar commands are run using "bootstrap-emacs -Q" then when the corruption occurs, the zero bytes are visible in the emacs buffer. As one of my experiments produced a good loaddefs.el, I did this: - start from a completely clean emacs-25 tree - overwrite ldefs-boot.el with the previously built loaddefs.el - do a full bootstrap, which succeeded. I do not know if replacing ldefs-boot.el with a freshly built loaddefs.el fixed the problem, or simply moved the timing around enough that this Heisenbug no longer occurred. AndyM