From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Bernhard M. Wiedemann" Newsgroups: gmane.emacs.devel Subject: Re: emacs reproducible builds part1 of 2 : eln Date: Wed, 22 May 2024 08:06:05 +0200 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; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18567"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: Eli Zaretskii , emacs-devel@gnu.org, =?UTF-8?Q?Mattias_Engdeg=C3=A5rd?= To: Andrea Corallo , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 22 08:07:22 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 1s9f8E-0004e5-DT for ged-emacs-devel@m.gmane-mx.org; Wed, 22 May 2024 08:07:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s9f7H-0000Vv-Dj; Wed, 22 May 2024 02:06:25 -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 1s9f78-0000UR-OE for emacs-devel@gnu.org; Wed, 22 May 2024 02:06:15 -0400 Original-Received: from mail.bmwiedemann.de ([2a01:4f8:221:b52:fcfd:ff:fe00:ec04]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1s9f76-0002u7-GX; Wed, 22 May 2024 02:06:14 -0400 Original-Received: from mail.bmwiedemann.de (localhost [127.0.0.1]) by mail.bmwiedemann.de (Postfix) with ESMTP id 0487C38CE; Wed, 22 May 2024 06:06:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lsmod.de; s=202205; t=1716357966; bh=X4BN9R2qhJqJiVp6pRfdNEBSI4XGGGPajj9SOY3tK38=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=egg4/7rCcm4tBaNZpomd6NIFmrUUWc8meD0pEOYwEBGD55+SEo2+0+MN81o6emV6p ch/kgQWqVlLbUzl322m5DHKQohDs7UKw9d0AZAWTWgcosOT/qketyzeuGU39KEi6r1 0MGianTcWpi8JoFgju2tZm1oSKNkaV8R1APT/m2NlUMCSKK4Li9QNPKwIPNt9Hz1ts aEl0wMx+WwYbL0kUPqjHXpbYMzwrYuVpUCeBkggBmqraJVoVPGRtC8LdGjR9B6ZCMl OQrCnut7z9oNgda37nfEbDHqZaY1fy7iEbEIaAuP14iLnE6OF6mb76OViim4Mjqzhu qQzSzVUYiJ4Yg== Original-Received: from [10.8.5.20] (unknown [10.8.5.20]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.bmwiedemann.de (Postfix) with ESMTPS; Wed, 22 May 2024 06:06:05 +0000 (UTC) Content-Language: en-US In-Reply-To: Received-SPF: pass client-ip=2a01:4f8:221:b52:fcfd:ff:fe00:ec04; envelope-from=bernhardout@lsmod.de; helo=mail.bmwiedemann.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:319472 Archived-At: 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. And finally there is still part2 left: .pdmp files have variations from some unknown source. Ciao Bernhard M.