From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#71774: 31.0.50; Hash table weakness broken? Date: Wed, 26 Jun 2024 10:38:42 +0200 Message-ID: References: <86ikxx9ib6.fsf@gnu.org> Reply-To: martin rudalics 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="4725"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 71774@debbugs.gnu.org To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 26 10:40:22 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sMOCS-0000o1-Fu for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 26 Jun 2024 10:40:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sMOCD-0006hM-Ks; Wed, 26 Jun 2024 04:40:05 -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 1sMOCB-0006e3-IY for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2024 04:40:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sMOC8-0000l1-CV for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2024 04:40:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sMOCA-0006gG-H6 for bug-gnu-emacs@gnu.org; Wed, 26 Jun 2024 04:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 26 Jun 2024 08:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71774 X-GNU-PR-Package: emacs Original-Received: via spool by 71774-submit@debbugs.gnu.org id=B71774.171939115925620 (code B ref 71774); Wed, 26 Jun 2024 08:40:02 +0000 Original-Received: (at 71774) by debbugs.gnu.org; 26 Jun 2024 08:39:19 +0000 Original-Received: from localhost ([127.0.0.1]:38446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sMOBT-0006f9-8D for submit@debbugs.gnu.org; Wed, 26 Jun 2024 04:39:19 -0400 Original-Received: from mout.gmx.net ([212.227.15.19]:56891) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sMOB2-0006a5-Q0 for 71774@debbugs.gnu.org; Wed, 26 Jun 2024 04:38:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1719391124; x=1719995924; i=rudalics@gmx.at; bh=RC0jVplhXUr2edYMPzcSDdZs0dZCtCBujEMmGx89aaY=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=r+cSb7qCPCmqHLOQhJC8PqbEs5MKKbhQ5hbq6W0xUjPX+7tlrt5KughvRxL822HC EEVBOEXUm/80NSRdS/3TZv8fNmigaxzQnSn5/z7JuYmPyFM5d+9o8kRCZn8qf4aCn b5RH5h54rU9hE32tk0pOrFuHPhyLIfpI6aG0oMkV/FXm/ary+5v0gnAK/Q1HF3VAp vmflvFtFtZIqlFBj67so+8bCi8kxm71CrmF1y65TIEZ9z9Tkz655PG6og16aF1h7f /jkI+8y7DtqnMeEygSJxvhxnEI4UxbARJJz+69rUG4w/AWL059XRPstp9AJqBtGhp lMr9QMepGSVyRewPxg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([213.142.97.45]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M89Gj-1sH8yd0dtb-00BKME; Wed, 26 Jun 2024 10:38:44 +0200 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:tsBZtOfWmh9sGpxg+kxuUnOZJ4v6F0InoQQzR0X0Ty2McJYCSEA qM601FDQ7VV5jUNpYNsHbCzubQLe8tKaF7E0ehvShhdoop9Iks37Q2Li9nPSMcDwR9RFE+4 it3ah4Ou/nR8PwOn7hbzBaiUAeVOQWsvHBaBuGbLztZWrSaJ0znbC1rXKlx3DUbwhQDKmeQ +gEIBnaqk8M2gvWq1jzjw== UI-OutboundReport: notjunk:1;M01:P0:VU9+CMbQrQA=;faJ+ZLRfVae1L8KpTY2Shw1Uenz EnM8u4adOAX5F+7euWJ6vL+I1jNwFchsVB8ypxW+d4Sng5TJXgfj6NpWODtmngRTzVPyCtuly +Y/ivhGtxSl28EiYVF9t0iFjHxDmLTx+EBPCGIVtNbDHesLePYtAtZ6OmVyGjmgclRFfCAO12 SurWkzub1FGRieLk/BJDuzoVpeMlpXGFqQlieL6OQ6Ev6G79DaTfu+HADQ1Udcb5XVNlVXhiE iwb3WnxYGww7OIVy0Rmo9+YjESIihqpGZ7L9HHF9V5B2DUsN/QeFKWTPYbf+9q9k8fbLANdP1 /RXiNrkc7A497XvMiQO8XU8hPHlRwe9wcJdauVkeuK21xAvLEbsy20p7CCnChWjd3d+DX8U+e Qe8egLy2zazVyhOtbn3d7eKIHMGpdBfravuXMSdZM6tPf89izCx98FzocPJCSROCoUR/UAjf7 NorRhhjEeLGKS/Bfrb/At249szizoOBbQFZrFZySsjA3suGdVawDNGFSs1bFoVHiKZt6XXBwU Ne1pUuKCGXi9xy+JR4x5/IDExhBG6Nrp4a8/iju8M9ZboSFJK4Pna/ggmZKe5iTEHsocC5XOc Ff6aH+j1QpQ9PnILdC+/jjMtDcROF6K1wNufOJxywosm79qO0P5ACfGie5E3ssdH72OARX5gp 1XI2n5PVXWqleank3IvW/ZTN5Kcdx2oeoCdMaeUHrxMaH0IKCtKkfd4FrHJzvQWVxB3kNH7i7 JPTxMh59o47dRzq+niJRgQo9NGhxQ+GxlvjxdR7OcITm3S5iojcQmvGKTFDNEs6hizKCs+Es X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287922 Archived-At: > Thanks for the report, but I wouldn't read too much into that. There > could always be a stray reference to an object that is otherwise > expected to be dead. Sometimes because of the conservative roots, > sometimes from internal state we don't think about. I tried once more with some 10 runs of automatic garbage collection triggered in between and the result is the same. Neither ambiguous roots nor internal state can explain that new behavior IMHO. > There is never a guarantee that any particular object is treated as > dead by the GC. It's more of a general ambition. A dead object that survives several collection cycles qualifies as a leak in my view. > As far as I can tell, it works as expected. Sometimes there is a > stubborn value that just doesn't seem to want to be collected, but > it's probably just a stray value on the stack, or a hidden reference > that got stashed somewhere by the REPL. This does not explain the change in behavior from all versions from Emacs 24 up to and including Emacs 29 here to the current behavior. A version of Emacs 30 from early October 2023 still works correctly here. A version from November 9th exhibits the new behavior. I can try to bisect from there but this takes much time on my slow machines. martin