From: Andrea Corallo <acorallo@gnu.org>
To: "Bernhard M. Wiedemann" <bernhardout@lsmod.de>
Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>,
"Eli Zaretskii" <eliz@gnu.org>,
emacs-devel@gnu.org,
"Mattias Engdegård" <mattias.engdegard@gmail.com>
Subject: Re: emacs reproducible builds part1 of 2 : eln
Date: Mon, 27 May 2024 13:33:03 -0400 [thread overview]
Message-ID: <yp1r0dnupm8.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <a14be49a-f100-4d41-ae7e-c77627c5763c@lsmod.de> (Bernhard M. Wiedemann's message of "Wed, 22 May 2024 08:06:05 +0200")
"Bernhard M. Wiedemann" <bernhardout@lsmod.de> writes:
> On 11/02/2024 11.24, Andrea Corallo wrote:
>> Andrea Corallo <acorallo@gnu.org> writes:
>>
>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>
>>>>>> So, I'm not sure it explains the phenomenon you're seeing (I haven't
>>>>>> seen the rest of this thread yet).
>>>>>
>>>>> Interesting, I imagined the walk order is defined but my question is
>>>>> what about two hash table with the same content but created in two
>>>>> different sessions?
>>>>
>>>> Depends how they were filled: if they were filles by the same sequence
>>>> of operations, then they should have the same walk-order.
>>>> If not, then all bets are off.
>>>
>>> Okay that's good news, I'll investigate more tomorrow, the case is
>>> pretty well defined now so should be possible to understand exactly what
>>> is going on.
>> Okay cool I pushed a fix in emacs29, with that installed we don't
>> try to
>> sort anymore conses based on their 'sxhash-equal' value because this is
>> not stable over different Emacs sessions. With the change installed the
>> build looks finally reproducible here.
>> Bernhard please let us know if this solves the problem on your side
>> as
>> well.
>
> Thanks for the fix.
> I had missed the email and only now got to retest.
> I found your commit
> 614b244a7fa03fcb27d76757e14ef0fa895d6f23
> is part of emacs-29.3 and the x-win.el compilation is now deterministic.
>
> The bad news is that there are still 4 more non-deterministic .eln files.
> I made a reproducer for one of them:
>
> cd ~/rpmbuild/BUILD/emacs-29.3/native-lisp &&
> for i in $(seq 10) ; do
> ../src/emacs -batch \
> --eval "(batch-native-compile t)" ../lisp/international/utf7.el &&
> md5sum 29.*/utf7.eln
> done | sort | uniq -c
>
> again with ASLR as factor in the result.
>
> The varying files are
> emacs/29.3/native-lisp/29.3-f8a6a23e/el-72f9fa70-1a554ff6.eln
> emacs/29.3/native-lisp/29.3-f8a6a23e/ox-9aa46d10-040d281c.eln
> emacs/29.3/native-lisp/29.3-f8a6a23e/utf7-8aab9346-0cfd2c82.eln
> emacs/29.3/native-lisp/29.3-fc431f4a/utf7-8aab9346-0cfd2c82.eln
>
> Unfortunately, the el.el and ox.el don't reproduce non-determinism the
> same way.
Just an ACK that I've reproduced the utf7 case and I'm working on a fix.
I'll look at the other afterwards (if the fix does not fix all of them).
Thanks
Andrea
next prev parent reply other threads:[~2024-05-27 17:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 21:17 emacs reproducible builds part1 of 2 : eln Bernhard M. Wiedemann
2024-01-12 8:22 ` Eli Zaretskii
2024-01-12 16:19 ` Andrea Corallo
2024-01-12 16:26 ` Eli Zaretskii
2024-01-13 9:52 ` Andrea Corallo
2024-02-10 16:35 ` Andrea Corallo
2024-02-10 17:45 ` Stefan Monnier
2024-02-10 18:31 ` Andrea Corallo
2024-02-10 18:44 ` Stefan Monnier
2024-02-10 20:37 ` Andrea Corallo
2024-02-11 10:24 ` Andrea Corallo
2024-02-11 20:13 ` Stefan Monnier
2024-02-11 21:44 ` Andrea Corallo
2024-05-22 6:06 ` Bernhard M. Wiedemann
2024-05-22 12:31 ` Eli Zaretskii
2024-05-27 17:33 ` Andrea Corallo [this message]
2024-05-28 15:20 ` Andrea Corallo
2024-05-31 7:26 ` Bernhard M. Wiedemann
2024-05-31 7:44 ` Andrea Corallo
2024-05-31 8:22 ` Bernhard M. Wiedemann
2024-05-31 10:45 ` Eli Zaretskii
2024-05-31 10:33 ` Eli Zaretskii
2024-01-12 16:14 ` Simon Tournier
2024-01-12 20:13 ` Eli Zaretskii
2024-02-12 7:10 ` Björn Bidar
[not found] ` <87il2ub1jy.fsf@>
2024-02-12 8:17 ` Andrea Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yp1r0dnupm8.fsf@fencepost.gnu.org \
--to=acorallo@gnu.org \
--cc=bernhardout@lsmod.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=mattias.engdegard@gmail.com \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.