From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: emacs reproducible builds part1 of 2 : eln Date: Mon, 27 May 2024 13:33:03 -0400 Message-ID: References: <8d01d73e-7ce1-4b3a-a25c-03b518a7e584@lsmod.de> <83jzofj70t.fsf@gnu.org> <83edemiklb.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24006"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stefan Monnier , Eli Zaretskii , emacs-devel@gnu.org, Mattias =?utf-8?Q?Engdeg=C3=A5rd?= To: "Bernhard M. Wiedemann" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 27 19:34:03 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sBeEU-0005zm-SU for ged-emacs-devel@m.gmane-mx.org; Mon, 27 May 2024 19:34:02 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sBeDf-0003gd-Nw; Mon, 27 May 2024 13:33:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sBeDc-0003gC-DN for emacs-devel@gnu.org; Mon, 27 May 2024 13:33:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sBeDZ-0007GC-70; Mon, 27 May 2024 13:33:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To: From; bh=6CbagnCjR5g5jALObdwGAJnnJxpNmj+RVPd1vc1OGJM=; b=Atkw2mcXsaZYDWaL2tOB NJ0jurYTemzoHJ6/0SSCiJUQesxcZZGA/r3LtsGyKt93xoOv7oXBJmv6U3xt1gWRtsL+wfE/+Djy3 SjfGuirQ6ftPj37n6VsEGPvEZp65px6fcM/thjanQhWkynz4QQXONcl+qUgmbaeGYauKGiwgA2FSL IACTWcZwWcov7cACX5RW0Btqwfy4/RWsMEfp8Ag867okHHE3qMWehjg7nlQO3LBMBb0NU/Q/fkHZd R9gn/1RPcu5/cJmT4/87rwfa3PgqPEjLQ6rNeIczP7qniftWbBW//Q4J4m3w6n5xPe9H08aKMWkzm +89mwYoylKRRjw==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1sBeDY-00042C-16; Mon, 27 May 2024 13:33:04 -0400 In-Reply-To: (Bernhard M. Wiedemann's message of "Wed, 22 May 2024 08:06:05 +0200") X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319618 Archived-At: "Bernhard M. Wiedemann" writes: > On 11/02/2024 11.24, Andrea Corallo wrote: >> Andrea Corallo writes: >> >>> Stefan Monnier 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