From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#71774: 31.0.50; Hash table weakness broken? Date: Tue, 25 Jun 2024 19:19:45 +0200 Message-ID: References: <86ikxx9ib6.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10622"; mail-complaints-to="usenet@ciao.gmane.io" Cc: martin rudalics , 71774@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 25 22:14:11 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 1sMCYN-0002XZ-Ff for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 25 Jun 2024 22:14:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sM9zu-0002XT-5s; Tue, 25 Jun 2024 13:30:36 -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 1sM9yo-00027e-64 for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2024 13:29:27 -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 1sM9wn-0004fh-5j for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2024 13:29:09 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sM9sj-0001Z3-Js for bug-gnu-emacs@gnu.org; Tue, 25 Jun 2024 13:23:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 25 Jun 2024 17:23:01 +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.17193361345955 (code B ref 71774); Tue, 25 Jun 2024 17:23:01 +0000 Original-Received: (at 71774) by debbugs.gnu.org; 25 Jun 2024 17:22:14 +0000 Original-Received: from localhost ([127.0.0.1]:37635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sM9rq-0001Xo-Fe for submit@debbugs.gnu.org; Tue, 25 Jun 2024 13:22:14 -0400 Original-Received: from [209.85.167.43] (port=50233 helo=mail-lf1-f43.google.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sM9rO-0001Wg-H8 for 71774@debbugs.gnu.org; Tue, 25 Jun 2024 13:22:02 -0400 Original-Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-52cdea1387eso3515460e87.0 for <71774@debbugs.gnu.org>; Tue, 25 Jun 2024 10:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719335987; x=1719940787; darn=debbugs.gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:from:to:cc:subject :date:message-id:reply-to; bh=UvJvUFNGXWrDSXqhbb+qSaHKfdFmciA399y5rJ9DurY=; b=Jy5Zpq0+TbTVxX/zdvTUL91+FhmoI71hlNRwllfhU6rNCHk7ZyaNtcDF6qHdYLs2N7 pyahy5VIaj0J+XesdQh/vcLcBsf/IYVmISMlW/R4Ch+c//FEShJp8Wkh+FWxokqdKwsw IxOS5j5522LuDhkexZf5itHmIRjcOWp9/sw4TwEEnbi+pkg0j6OGPE6654d1V704e6hb Kgn3kyLDtzbJLSIQioZUi+I8ebynjUdgRWFjL4WMIxmu72MTvgOcQFC4rvrJL43uU2Bf nSIvg/vYSaLGwfyXWRAIeamrECj1NYqcmVNJ0QsEInY6W/NzzsFjU6QKCSqKkQMEimZ4 Vv+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719335987; x=1719940787; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:sender:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UvJvUFNGXWrDSXqhbb+qSaHKfdFmciA399y5rJ9DurY=; b=uiD6cAfGgDqck9zmPXDpEa2ELsPzhBCr0ac5+LGpuQ4qYa9e6m6e/+IO1zJGDo+fPu K4JXiBzXZzBVo+DPMP8E26cGN90H0BS+1ZDP/cWEhNSMxEAdQNVj0kFTNkQjNkX0Pn2c iZX+jT5la+PyLqWEyagTYBasCz1ld4Cc3RQe9YrMkJ5mqUtfPIVewHhpja4mi+fVdofr SXNjB6ASoxdJ3WuByU9YmYnqrMa2gurzHa/aAPh0uQoDxcjAzKd2O3c8226pYbLEn2NP Okq/Ri5vko/ej7tQgEuJ7378q/1SQakIoNSFRj0eeeY55zL6NlUk9kIcNJRTm3BZnNeE wuCA== X-Forwarded-Encrypted: i=1; AJvYcCVdpIZ84cRu7dTrQkRfUxQKXsHvw6aBtRx23am33B5jKZCzQKnLU17tpS3ik0si9YgBnhw18zxfykTIivv8SQaDo+HJSqQ= X-Gm-Message-State: AOJu0YxtyzEEsr5F2sHuOWOn1Zj9eITwzBHcGrWew8nK9Tl1qDOleIpH 94TOBbATyYy5PUoPdunY9IiUs5U3lwjpdOzxSlpb081ghdPwIcoS X-Google-Smtp-Source: AGHT+IG8Elaqhl0l3NE2b8MzrPbhPninWsv+BMh7Bwx6a/CA6sjOElu8gCWpuXMlJKeolA7A/+cyLg== X-Received: by 2002:ac2:4838:0:b0:52b:c27c:ea1f with SMTP id 2adb3069b0e04-52ce185faa8mr4291073e87.55.1719335987008; Tue, 25 Jun 2024 10:19:47 -0700 (PDT) Original-Received: from smtpclient.apple (c80-217-1-132.bredband.tele2.se. [80.217.1.132]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-52cec5db055sm300161e87.69.2024.06.25.10.19.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jun 2024 10:19:46 -0700 (PDT) In-Reply-To: <86ikxx9ib6.fsf@gnu.org> X-Mailer: Apple Mail (2.3654.120.0.1.15) 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:287900 Archived-At: > The last form evaluates to # here. In all prior Emacs > versions I have it evaluates to nil. IIUC this means that either hash > table weakness is broken or there is a bug in the collector. To = exclude > that the behavior is specific to the window handling code, note that = the > recipe you can find here >=20 > https://nullprogram.com/blog/2012/12/17/ >=20 > is now broken too. 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. There is never a guarantee that any particular object is treated as dead = by the GC. It's more of a general ambition. 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.