[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Build failure for Emacs master
From: |
Andy Moreton |
Subject: |
Re: Build failure for Emacs master |
Date: |
Fri, 15 Apr 2016 09:18:58 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.92 (windows-nt) |
On Fri 15 Apr 2016, Eli Zaretskii wrote:
>> From: Andy Moreton <address@hidden>
>> 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
- Re: Build failure for Emacs master, (continued)
- 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, 2016/04/14
- 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 <=
- 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
- Re: Build failure for Emacs master, Angelo Graziosi, 2016/04/19
- Re: Build failure for Emacs master, Paul Eggert, 2016/04/19
- Re: Build failure for Emacs master, Angelo Graziosi, 2016/04/20