From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 14:48:15 +0300 Message-ID: <864j74j2bk.fsf@gnu.org> References: <8b1c8e1f-e0b9-4049-888c-3f723e0008a9@gmail.com> <86v7zqmdo5.fsf@gnu.org> <86bk1gxz1z.fsf@mail.linkov.net> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9136"; mail-complaints-to="usenet@ciao.gmane.io" Cc: execvy@gmail.com, 72692@debbugs.gnu.org, juri@linkov.net To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 28 13:49: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 1sjHBA-0002Ba-6q for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Aug 2024 13:49:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sjHAk-0001eZ-CY; Wed, 28 Aug 2024 07:49:10 -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 1sjHAj-0001eI-42 for bug-gnu-emacs@gnu.org; Wed, 28 Aug 2024 07:49: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 1sjHAi-0005H4-Nv for bug-gnu-emacs@gnu.org; Wed, 28 Aug 2024 07:49:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=9Aw+dguqzJyjzNaGz0fAv4vKci0P05T1r1VkSNpBxBE=; b=fAJsZGz9d3XrnWvtgk73g9FIcPWtcafwO5HWejA7l07wB9qwWvj1nOjsy27RAMzxKsB0SRdsBYO3pufKvyvbSpI5eNvG9CpWxlcUJXkzdFnLB8RlDI5GNsvsLsJkX0Ch7OTl/xlpTRkeXz6lkFDSjFjonZpG4HQxWDKhaaF4ffH/VxPlw18zNS5oyCPwicXmJX16yojNe4kxIbz5NCrAKNzDP08fvYpzl45JvjuZeS1iwg43j7yE1YSR3Cu7jEqMFraexSXFaxBhBChQS6QQotsLW3bpLRKFBC2nIAJh9/TCkb3IffHZuwKySszSHheg832z3e5E6xTp3OpL2I+p9g==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sjHBa-0001OD-JI for bug-gnu-emacs@gnu.org; Wed, 28 Aug 2024 07:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Aug 2024 11:50: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.17248457655258 (code B ref 72692); Wed, 28 Aug 2024 11:50:02 +0000 Original-Received: (at 72692) by debbugs.gnu.org; 28 Aug 2024 11:49:25 +0000 Original-Received: from localhost ([127.0.0.1]:48329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sjHAy-0001Mk-Vm for submit@debbugs.gnu.org; Wed, 28 Aug 2024 07:49:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sjHAu-0001MQ-Ml for 72692@debbugs.gnu.org; Wed, 28 Aug 2024 07:49:23 -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 1sjH9w-0005D4-0m; Wed, 28 Aug 2024 07:48:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=9Aw+dguqzJyjzNaGz0fAv4vKci0P05T1r1VkSNpBxBE=; b=TNqRNDo4LjcT Wsu5OLC4vdQoC+tNtrLRVb+gCgK+hVc5FjU+4sYp0Hgio4c2+PbjgKeanRWGHHHR8L5QEdogDRx1k T06yTamXvvfBtnaLsd1AfJmiS5Qkfg/czO5A3hdxxrKu3zyk7WGVWeJXMXHz2TidyFhlFSj436B7O uxJcdlfKJHUo6GP/t9ttPtOgaTy+YDZtXs7vGHtU7lhLywhW+uX8v+totbjimlfVzQdYGZZwbIUk1 a42P5ijn8AFs/7EnU++cCcCoaEZ6IsATDIyVKI3TkedZ1ipnD/WTXnKeRm72mqpxWwk6WSOeeczTj WcTYAbHWWWfGO3FmQ8uwgw==; In-Reply-To: <8734mp22ed.fsf@protonmail.com> (message from Pip Cet on Tue, 27 Aug 2024 19:26:21 +0000) 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:290857 Archived-At: > 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. > >> 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. (But in that case we don't lose anything, since the test of cache->used = 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.