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: Tue, 28 May 2024 11:20:21 -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="437"; 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 Tue May 28 17:21:37 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 1sByds-000ASx-HY for ged-emacs-devel@m.gmane-mx.org; Tue, 28 May 2024 17:21:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sBydF-00084h-PP; Tue, 28 May 2024 11:20:57 -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 1sBydD-00084C-Aj for emacs-devel@gnu.org; Tue, 28 May 2024 11:20:55 -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 1sBydC-0001qv-4h; Tue, 28 May 2024 11:20:54 -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=IwkWR6MgkzQSlUbUV4Nomw+wjUY/YHx89Zsh3Iw9K38=; b=GV1g+BVdASxSS59tV6iR UW7fgBOky7joWAn5ciO303J6+ssdExjXtxx8ieO4cB4YHMypQZJrYov5bnvMmIX82+Wywdj3Adu9Q CyDbMkYSDo6mhDeYQhGZI/APOiOxU7nHUTLyCnphTmFW8GXwXQBcPHDHpGHXuiNTG1tsdqflFTavU MKYmo1VcXlqdWNWzFpqTVnDAdFIdvLEFffyWVe5AtvzDoVs5QdizAC+WO3FYBFX2QKUaMIletjzlI tkarQaTIApKfV5uG72xIar10CqUI5sm1Y4F4d0U3j83oCO0F2L9vWieexDEnszcpS0UmsSVsMCQBH BobLzHCUAHPUTg==; Original-Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1sBycf-0004Fy-OA; Tue, 28 May 2024 11:20:32 -0400 In-Reply-To: (Andrea Corallo's message of "Mon, 27 May 2024 13:33:03 -0400") 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:319653 Archived-At: Andrea Corallo writes: > "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). Hi Bernhard, could you verify that after 509e7f877ba those elns are now stable for you? Building lisp/cedet/semantic/bovine/el.el, lisp/org/ox.el and lisp/international/utf7.el looks stable on my test-bed here. Thanks Andrea