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: Fri, 15 Apr 2016 09:18:58 +0100 Message-ID: <86k2jzgu8d.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> <864mb4j5lw.fsf@gmail.com> <837ffze3dx.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1460708425 21152 80.91.229.3 (15 Apr 2016 08:20:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Apr 2016 08:20:25 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 15 10:20:16 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 1aqyz8-0000SJ-GE for ged-emacs-devel@m.gmane.org; Fri, 15 Apr 2016 10:20:14 +0200 Original-Received: from localhost ([::1]:57199 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqyz7-000844-Nb for ged-emacs-devel@m.gmane.org; Fri, 15 Apr 2016 04:20:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqyyo-000808-IH for emacs-devel@gnu.org; Fri, 15 Apr 2016 04:19:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqyyk-0006q5-HP for emacs-devel@gnu.org; Fri, 15 Apr 2016 04:19:54 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:46417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqyyk-0006pv-7T for emacs-devel@gnu.org; Fri, 15 Apr 2016 04:19:50 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aqyyf-0000Fq-WD for emacs-devel@gnu.org; Fri, 15 Apr 2016 10:19:46 +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 ; Fri, 15 Apr 2016 10:19:45 +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 ; Fri, 15 Apr 2016 10:19:45 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 105 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:/lgicHTk4zz0yZFRoxrgpMfO+e8= 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:202944 Archived-At: On Fri 15 Apr 2016, Eli Zaretskii wrote: >> 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. I can reproduce this repeatably from running make, or after building bootstrap-emacs.exe using just the command line used to update loadddefs.el. Attempts to debug with bootstrap-emacs -Q and evaluating the equivalent commands in the scratch buffer (or loaded from a file) do not show the problem. Running under gdb gives variable results. >> > 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. Noted, but here I am building from a clean tree so that loaddefs.el does not exist. >> 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. The changes I see are: - timestamp changes - changed autoloads from your changes to grep.el - changes to the files listed in the comment at the end. --[diff ldefs-boot.el loaddefs.el]------------------------------------ @@ -12876,16 +12829,22 @@ The default grep program for `grep-command' and `grep-find-command'. This variable's value takes effect when `grep-compute-defaults' is called.") -(defvar find-program (purecopy "find") "\ +(custom-autoload 'grep-program "grep" t) + +(defvar grep-find-program (purecopy "find") "\ The default find program. This is used by commands like `grep-find-command', `find-dired' and others.") -(defvar xargs-program (purecopy "xargs") "\ +(custom-autoload 'grep-find-program "grep" t) + +(defvar grep-xargs-program (purecopy "xargs") "\ The default xargs program for `grep-find-command'. See `grep-find-use-xargs'. This variable's value takes effect when `grep-compute-defaults' is called.") +(custom-autoload 'grep-xargs-program "grep" t) + (defvar grep-find-use-xargs nil "\ How to invoke find and grep. If `exec', use `find -exec {} ;'. --[diff ldefs-boot.el loaddefs.el]------------------------------------ Should the define-obsolete-variable-alias forms for find-program and xargs-program be marked as autoloads ? >> 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? No, but changing the content of ldefs-boot.el can change the timing and behaviour of the bootstrap-emacs.exe that is built from it. Whether the observed bug is timing related or completely deterministic is not yet known. AndyM