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: Fri, 15 Apr 2016 10:29:30 +0300 Message-ID: <837ffze3dx.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> <83fuuodm1q.fsf@gnu.org> <864mb4j5lw.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1460705420 7211 80.91.229.3 (15 Apr 2016 07:30:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Apr 2016 07:30:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 15 09:30:15 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 1aqyCj-0001rB-Vw for ged-emacs-devel@m.gmane.org; Fri, 15 Apr 2016 09:30:14 +0200 Original-Received: from localhost ([::1]:56415 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqyCj-0005wP-7i for ged-emacs-devel@m.gmane.org; Fri, 15 Apr 2016 03:30:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqyCU-0005tO-IZ for emacs-devel@gnu.org; Fri, 15 Apr 2016 03:29:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqyCP-0002K8-J1 for emacs-devel@gnu.org; Fri, 15 Apr 2016 03:29:58 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqyCP-0002Jx-FV; Fri, 15 Apr 2016 03:29:53 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1597 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aqyCO-00029Q-Lq; Fri, 15 Apr 2016 03:29:53 -0400 In-reply-to: <864mb4j5lw.fsf@gmail.com> (message from Andy Moreton on Thu, 14 Apr 2016 21:30:19 +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:202943 Archived-At: > From: Andy Moreton > Date: Thu, 14 Apr 2016 21:30:19 +0100 > > >> (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. You said you can reproduce this at will, so I thought doing that is not a problem, and then the values would be the same as in this run. Apologies if I misunderstood. > > 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 The last part is only true if there's no loaddefs.el file in the tree. See the commentary and the relevant code in loadup.el. If loaddefs.el does exist, bootstrap-emacs build will use it. > 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. What are the differences between that "successful" loaddefs.el and ldefs-boot.el which produces a corrupted loaddefs.el? The only changes I see are in the time stamp cookies. > 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. Sorry, I don't understand: what timing could change as result of modifying one of the inputs? Are you saying that the differences (in size or content) are so significant s to affect the time to read the file into memory?