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: Mon, 19 Aug 2024 14:30:09 +0300 Message-ID: <86jzgcycla.fsf@gnu.org> References: <8b1c8e1f-e0b9-4049-888c-3f723e0008a9@gmail.com> <86h6biymv4.fsf@gnu.org> <8734n2gd2x.fsf@protonmail.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37765"; mail-complaints-to="usenet@ciao.gmane.io" Cc: execvy@gmail.com, 72692@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 19 13:31:43 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 1sg0bv-0009hx-JY for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Aug 2024 13:31:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sg0bc-0004Lc-Qg; Mon, 19 Aug 2024 07:31: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 1sg0bY-0004Jt-I3 for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2024 07:31:21 -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 1sg0bY-0007oQ-9D for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2024 07:31:20 -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=jTmgDtrx5u4LDecCB5cnlh25jKq6GOKzzFSXOQ1xeq8=; b=r2RqL9rerfEFNm1S7iM3EyaB8KHVMzFxrDuNA/UqwqK7LstfF7HfE/k56lhMUHFjIDzATcUJiiGDR2+8uoguOhm+ugjWfRAHvkZ8rR+jql7NkP05i5B+Nh12s87gk7kQUs1pKDDQQFLTR2DCXYDNuk5p2RHvEptbBgAkY+4erpaVisRz3V5jOt64NdSBe/XcpS+4z4U3BIP+CkyFQp8wpmQqQmIAezLFwsLgtNjtnFmS0XNPKUbYQ82q/pmERqFAKUvnsOPjfpLuxZ7SFx308Bg/GttAx8SKtf9xaMKLU4/NQrp0fdQADpd9/+EiUrb8nTJQWGsSv6NeBmaQ+zTCMg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sg0cD-0000sv-IA for bug-gnu-emacs@gnu.org; Mon, 19 Aug 2024 07:32:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Aug 2024 11:32: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.17240670813351 (code B ref 72692); Mon, 19 Aug 2024 11:32:01 +0000 Original-Received: (at 72692) by debbugs.gnu.org; 19 Aug 2024 11:31:21 +0000 Original-Received: from localhost ([127.0.0.1]:57761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sg0bY-0000ry-PB for submit@debbugs.gnu.org; Mon, 19 Aug 2024 07:31:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sg0bV-0000ri-ID for 72692@debbugs.gnu.org; Mon, 19 Aug 2024 07:31:18 -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 1sg0ak-0007kC-Fe; Mon, 19 Aug 2024 07:30:30 -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=jTmgDtrx5u4LDecCB5cnlh25jKq6GOKzzFSXOQ1xeq8=; b=awnz0Cz0TRN1 863TpN5cnel5KJ5c72wqCpHeWyqQLZX+ooRlJKqdEyek3fveaWFoZLTLJ83E7RVdqSsf+pMP1gMqp 0qI9oyCbgKWUJV1zVDZ7VBEUedL03sRuBSbCk89H7gK4NSZElZqjEMqwMUkDJw0qp++OdRM9x+gAa oxvF87rQWUJV48pDHfBcI5wsA/eeCht5ZLtQpoP3mSMq0b/nTdZqvcaB4+k8+/PVwUrUwX+be09ar 1A5n7SYSxHZWu78eO+4d3NmGsKA/z3P30q1upiIv21Q6XsyINkWR2F6fjMGckkrQt3hZH7RQt4J7v oIuimTvDQnTYy/+8PrKgmA==; In-Reply-To: <87ttfhdo1e.fsf@protonmail.com> (message from Pip Cet on Mon, 19 Aug 2024 06:28:32 +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:290382 Archived-At: > 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. And your description sounded like the problem could happen quite frequently even without that patch. > * 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? why not buffer text? Mixing different fonts (i.e. non-ASCII faces) in the same buffer is quite common in Emacs; e.g., try "C-h h". Also, why do we need more than one non-ASCII face to trigger the problem? > * 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. > * be unlucky in your choice of malloc implementation "Unlucky" in what sense? And if all the users of GNU/Linux (i.e. glibc) are thus "unlucky", this still leaves us with many potential victims. > 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.