From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#72692: Emacs 31.05 (40eecd594ac) get SIGSEGV on Linux (Linux 6.6.45 Kde Wayland) Date: Wed, 28 Aug 2024 11:58:48 +0000 Message-ID: <87r0a8zwne.fsf@protonmail.com> References: <8b1c8e1f-e0b9-4049-888c-3f723e0008a9@gmail.com> <86v7zojuqw.fsf@gnu.org> <87y14j25mg.fsf@protonmail.com> <86cylvjw5l.fsf@gnu.org> <87r0ab14ye.fsf@protonmail.com> <87mskz146e.fsf@protonmail.com> <86zfoyi3wj.fsf@gnu.org> <8734mp22ed.fsf@protonmail.com> <864j74j2bk.fsf@gnu.org> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10140"; mail-complaints-to="usenet@ciao.gmane.io" Cc: execvy@gmail.com, 72692@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 28 13:59:36 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 1sjHKq-0002Sl-2w for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Aug 2024 13:59:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sjHKR-0003c0-5K; Wed, 28 Aug 2024 07:59: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 1sjHKP-0003bj-1l for bug-gnu-emacs@gnu.org; Wed, 28 Aug 2024 07:59:09 -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 1sjHKO-0006NF-PM for bug-gnu-emacs@gnu.org; Wed, 28 Aug 2024 07:59:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:From:Date:To:Subject; bh=KY/ADgd8YlkUzBxsfMivIZMsGPmgC2MLMTl4AGcGlpE=; b=otNeNrIx2A57BU/RHGlvuzjPBUH213A2RHKLrfsBUsyPAKDrMdmzYMGCv5f4qAk1wZT9C4ElSu4YiAz6Zp0AWnZEBZCUDW9lqnexvi/OYb8nB4/wA41pm75mR+9DQwgtkszIPy8i2YiMZ59Ssf9jW+PLPbOzhw5JEsE/LHd2RRIio1//mlx1F1zudvSBuj5gwW8V8rHh2YfeAE6Q9Cwiokh4zd4CVcTUPTNyyHo2AWkOkRgMNzyXpy1ahgUkdzXD7776nHLYtosINN+gsdDW/GrXK+LBFHqo7AVb4mGhzeiynrR+nSR/6wpxzc5zdzuokGVGdm+bQY6zsibxwJly+w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sjHLG-0001gx-Lr for bug-gnu-emacs@gnu.org; Wed, 28 Aug 2024 08:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Aug 2024 12:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72692 X-GNU-PR-Package: emacs Original-Received: via spool by 72692-submit@debbugs.gnu.org id=B72692.17248463966459 (code B ref 72692); Wed, 28 Aug 2024 12:00:02 +0000 Original-Received: (at 72692) by debbugs.gnu.org; 28 Aug 2024 11:59:56 +0000 Original-Received: from localhost ([127.0.0.1]:48360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sjHL9-0001g6-H3 for submit@debbugs.gnu.org; Wed, 28 Aug 2024 07:59:55 -0400 Original-Received: from mail-40133.protonmail.ch ([185.70.40.133]:26319) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sjHL7-0001fq-5Y for 72692@debbugs.gnu.org; Wed, 28 Aug 2024 07:59:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724846332; x=1725105532; bh=KY/ADgd8YlkUzBxsfMivIZMsGPmgC2MLMTl4AGcGlpE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=LFTv+i3hIh5+4w/su4ds8bQmOf7h79ThO89pAxibSp5zhi7o1QqZ0NSCW+7izGDJ7 YCwZoGrwo8DcLrLl7qzED0jvzSME8bg3wlGTp4vpfSVw1GdYIvjUz6qKJZ36KFiij9 cTbviIwmuCpcAvLr5Ip5rmOfNS6aadKwGVrTBoQ27AFwje2fjoqNlzpkKxaTOvn7lC 69qdVXH9iJ5y5dy0fU7t6Ztzg8tXLCzlvd9xQs0hW1MsQj8s/sL5NzVRt4hfz/kRGr R3Xv19uC9LCuw44CFhdUFjoCGRKb5y+VjC9Rk6lclE7teqBWyq8iUXdxoRzzPA5x3J IQ3tFdbLtlG4Q== In-Reply-To: <864j74j2bk.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0d07c426c8d0a98fa7e41379383be753fe849948 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:290859 Archived-At: "Eli Zaretskii" writes: >> Date: Tue, 27 Aug 2024 19:26:21 +0000 >> From: Pip Cet >> Cc: execvy@gmail.com, 72692@debbugs.gnu.org, juri@linkov.net >> >> "Eli Zaretskii" writes: >> >> > That was the main idea of the patch I proposed, except that avoiding >> > to set the face_change flag when all we have in the cache are the >> > basic faces is a bit stronger, no? >> >> Indeed. I think your proposed patch is the way to go, with the >> off-by-one fixed. I think there will be some slowdown for people using >> non-ASCII faces in the modeline, in particular, but it should still >> result in acceptable performance. > > Displaying the mode line calls init_iterator exactly once, AFAICT, so > I don't expect any special performance issues due to that. I think you're right, and that I was confused. >> >> Is that case sufficiently common to result in acceptable >> >> performance? >> > >> > Which case? >> >> That only basic faces are realized, and we can therefore avoid freeing >> any cached faces. > > If you mean "only basic faces are realized" as opposed to "face cache > is empty", then it's quite possible that they are the same situation, > at least now. I think I saw a backtrace in which the basic faces were realized, but I'm not entirely sure and I don't think it matters; your patch should work and is the way to go. > (But in that case we don't lose anything, since the > test of cache->used =3D 0 is not cheaper than cache->used > SOMETHING.) > But if you mean "face cache is empty", then I think this situation is > quite common, yes. People nowadays write Lisp code that creates and > modifies a lot of faces, and every change in the faces on the Lisp > level causes us to set the face_change flag, which then causes us to > empty the cache. Correct, but as we don't lose anything by performing your optimization, let's go with that, assuming it survives testing and you don't come up with something even better? Pip