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: Mon, 19 Aug 2024 13:32:42 +0000 Message-ID: <87frr0eiyy.fsf@protonmail.com> References: <8b1c8e1f-e0b9-4049-888c-3f723e0008a9@gmail.com> <86cym5zzq9.fsf@gnu.org> <87y14tg9ln.fsf@protonmail.com> <865xrxzvrt.fsf@gnu.org> <87ttfhg6ey.fsf@protonmail.com> <87plq5g1fo.fsf@protonmail.com> <86v7zxy8ur.fsf@gnu.org> <87ttfhdo1e.fsf@protonmail.com> <86jzgcycla.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="10170"; mail-complaints-to="usenet@ciao.gmane.io" Cc: execvy@gmail.com, 72692@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 19 15:33:46 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 1sg2W1-0002Q5-Nm for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Aug 2024 15:33:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sg2Vg-0002i1-Fw; Mon, 19 Aug 2024 09:33:25 -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 1sg2Ve-0002ho-OR for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2024 09:33:22 -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 1sg2Vd-0001xD-2w for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2024 09:33:22 -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=7LIVhKDYn+upguSrpaIJUSZFjFB8e/QZ/mUAetJEUQM=; b=G+WMbxtMnn201BsNgZMKdAPvPLQBIsYOn7XM7l0OI/U9HeZs8I668Yq1SIfVhPpialHC7iCTEXVOSlSwUOcQKTjfPuchDRxiV11o06iJoEVdMM87rXY0se9PHoJi1W/4SgMA5sRupiYpdundwZvuBgUyMZw2DrqOER0V9NzzMWsrk0F9x5Ku9oLqCS/D1xA/sj9ZugvydldyN9Oe++t2yT+42Z/8Jty2z8oRA2AKtmUf5LuBG8F3J+CmkeY1Ue1aTXXja4uvUNTF+bikJgJ+xJN26bPsGt0KF3mij6kjcZJ+pBO54B1BypVuU08adgpU6CwdPGn/3LSrgqJV/Hvj6g==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sg2WH-0004Nf-RN for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2024 09:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Aug 2024 13:34:01 +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.172407441816807 (code B ref 72692); Mon, 19 Aug 2024 13:34:01 +0000 Original-Received: (at 72692) by debbugs.gnu.org; 19 Aug 2024 13:33:38 +0000 Original-Received: from localhost ([127.0.0.1]:57925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sg2Vt-0004N0-1U for submit@debbugs.gnu.org; Mon, 19 Aug 2024 09:33:37 -0400 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]:21753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sg2Vq-0004Mi-8H for 72692@debbugs.gnu.org; Mon, 19 Aug 2024 09:33:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724074366; x=1724333566; bh=7LIVhKDYn+upguSrpaIJUSZFjFB8e/QZ/mUAetJEUQM=; 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=Lo23CzDCznHBe0PM+RwCjrG/KI7hAGmIu5jOpg6rbzxVMqyKYyIa7Vqh/7WZmaH2f XxW8cyxud9Kyg8DZlgfSYrZzXZMifL6YmGOb6aOk/SM388oP8UBRShp3XrSN7kd7FX yppHQtRFi4L97yIL46U/XqYeoBTo4rjP8qv+c2Cz3j4KV5/WlBwRVICfAVkSnBn2PW 3iW3uEYXib7TNQ7BptAc/jbYh4JDa/+JGI/CoV/bemFNCZ4AdAgQeMEsvfW3JwNHL+ UCPnqt/U3jfMaE1Ml09X/f1DkrFkBnjTqBjOIaLSWYv2ybASCPXy7Ouz/5oEUkWOZg 0Biu9cAsaLPhw== In-Reply-To: <86jzgcycla.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: fcc44b44a07889093b390a8e3702d5d8ad128784 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:290392 Archived-At: "Eli Zaretskii" writes: >> Date: Mon, 19 Aug 2024 06:28:32 +0000 >> From: Pip Cet >> Cc: execvy@gmail.com, 72692@debbugs.gnu.org >> >> "Eli Zaretskii" writes: >> >> > Here's one data point: this kind of problem has never, NEVER happened >> > to me, although I display non-ASCII text in my Emacs sessions quite a >> > lot. So if what you describe is so trivially easy to trigger, how >> > come it didn't happen to me, in all the years I'm using this code? >> >> It isn't trivially easy to trigger at all! To trigger it reliably, you >> need to: >> >> * apply the patch so we don't reuse fontset table entries, which >> otherwise hides the bug > > But the OP didn't use that patch. Indeed, and got rare (about once a day) crashes, even though they met all other criteria for them. > And your description sounded like > the problem could happen quite frequently even without that patch. The crashes are infrequent, since we will silently use the wrong fontset rather than crashing if its ID has been reused. Using the wrong fontset would be much more common, but lead to very subtle bugs which I haven't seen (nor am I sure how they would show up). >> * modify the mode line to use two new non-ASCII faces, at once, by >> inserting two characters provided by different fonts > > Why does it have to be the mode line? It doesn't, but that gets us into the murky territory of what is and isn't the same bug. > why not buffer text? Seems to cause the crash as well, via 'realize_default_face' > Also, why do we need more than one non-ASCII face to trigger the > problem? I don't know. As I said, I'm trying to understand that, but I think it's a minor detail: we know the crash happens, we can reproduce it (changing only things that make crashes more likely but shouldn't affect correctness), we know why it's apparently rare (fontset slot reuse, malloc() returning a freed face's block, the two non-ASCII-face thing). >> * modify the right frame parameter (such as alpha-background) so that >> the basic faces are re-realized ('free_realized_face' is called for >> them), but 'free_realized_faces' is not. > > Basic faces are routinely freed and re-realized whenever we start the > display iteration, see init_iterator. > AFAIR, all you need to do for > that is to customize some face -- doing so sets the face_change flag, > and init_iterator will then normally free all the faces and realize > them again. ... which won't trigger the bug, because it calls 'free_realized_faces'. I specifically explained why 'free_realized_face' must be called directly, not via (or after) 'free_realized_faces', to trigger the bug. >> * be unlucky in your choice of malloc implementation > > "Unlucky" in what sense? Have a malloc which returns a recently-freed block of appropriate size for the next allocation. > And if all the users of GNU/Linux (i.e. glibc) are thus "unlucky", > this still leaves us with many potential victims. Indeed, which is why we should fix the bug. >> In particular, I'd like to understand why we need to use two non-ASCII >> faces at once. > > Maybe I don't understand the question, but we need a new non-ASCII > face each time we find a character for which existing non-ASCII faces > don't have a glyph. I meant why we need at least two non-ASCII faces to trigger the bug. Here's a reproducer hibiscus.el which uses buffer text: (while t (insert (concat (make-string 1 (floor (random 132000))))) (set-frame-parameter nil 'alpha-background 1.0) (sit-for 1.0)) It does, however, need at least two characters to crash, so the "why two non-ASCII faces" problem remains. Pip