From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Evgeny Zajcev Newsgroups: gmane.emacs.bugs Subject: bug#66589: 30.0.50; core dump in redisplay Date: Tue, 17 Oct 2023 16:36:17 +0300 Message-ID: References: <83jzrlo5au.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003d7d0e0607e99c4d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32821"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66589@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Oct 17 15:38:04 2023 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 1qskGp-0008K4-J1 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 Oct 2023 15:38:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qskGS-00081j-Fc; Tue, 17 Oct 2023 09:37:40 -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 1qskGP-00081M-0i for bug-gnu-emacs@gnu.org; Tue, 17 Oct 2023 09:37:37 -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 1qskGO-00030z-OZ for bug-gnu-emacs@gnu.org; Tue, 17 Oct 2023 09:37:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qskGn-0000Sw-Tn for bug-gnu-emacs@gnu.org; Tue, 17 Oct 2023 09:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Evgeny Zajcev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Oct 2023 13:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66589 X-GNU-PR-Package: emacs Original-Received: via spool by 66589-submit@debbugs.gnu.org id=B66589.16975498251706 (code B ref 66589); Tue, 17 Oct 2023 13:38:01 +0000 Original-Received: (at 66589) by debbugs.gnu.org; 17 Oct 2023 13:37:05 +0000 Original-Received: from localhost ([127.0.0.1]:58889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qskFs-0000RP-6i for submit@debbugs.gnu.org; Tue, 17 Oct 2023 09:37:04 -0400 Original-Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]:53454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qskFp-0000Qk-U7 for 66589@debbugs.gnu.org; Tue, 17 Oct 2023 09:37:02 -0400 Original-Received: by mail-pf1-x42c.google.com with SMTP id d2e1a72fcca58-6b5cac99cfdso3005465b3a.2 for <66589@debbugs.gnu.org>; Tue, 17 Oct 2023 06:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697549790; x=1698154590; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=t8nZUdgO9fn1vJPF1S+T4Qm16csF+T82iNMOjQooeU8=; b=jWX8nv/7EcKRlNT2a7fccWdO9jXm19r8B5qdKiQInGDjxrtu8MfLqM7cXLGqTZ0NN0 xcp+yA5wkcQLzFcMuOAPBiEww6Cv1gqRCOHttxaGDBbD6s4jBmy3vccTBHR4keRkDepK vGzP8uywFl63FHs6y4+fH8SCXXQmwKBC5umtPfdrcy0BXXS/A0KLtFmgedPGztlN+YBw +gmdYlrU2kEl+1PGMR9Jv6361N69CGmlGsiY7NTydJRUJtoP8rqHCnMpywp2ToQGxz8t SxPksFTxIeeOcdot9tjan0juWJYnEaLX8pxNwwciVPUof95kowRB9jyhLdEqx+97TWJQ GNDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697549790; x=1698154590; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=t8nZUdgO9fn1vJPF1S+T4Qm16csF+T82iNMOjQooeU8=; b=podIkB0xNAudv59Vr7V1vz96zPcbdVNKm1WgDsiZmVThUrVKF2K4AZeTsUykFcR9Q2 LNza/BuUMBu56OZS24IQq172waWBHP2Uay+Alom2+1Fs8lHHOnnu7cdLtDWf8RXh9sEj F9yJZu+CwPzVectU48a7aEiIM+mnZBKbliyQLlJb927UsLsl06Trpg54z4294pvG3hND TbKh9oDCY75QN5a7g+zZ7xGNjwrTUqN8lW/CSLY4c65iETMy8FBRTLovRaeaoP5ryyWE GhZw3f5La+pMk7SOuMKkj+5BvA9A/2PbSaRdaq+oXRjEHT3DO3jgQvdlSCSjK5DhuwmH 8THA== X-Gm-Message-State: AOJu0YwStxh3Pha2YnVwvZmJhsMUgZkrXe4YuMU9cretr6hDSa/FtVzI yHqaufKiNdmMPNJYQnekkadKEQyiIsGpLu/QsaQ= X-Google-Smtp-Source: AGHT+IHdE2gwue8mShxVrFXh7PrEWAZlJO9K+I9Tck7d7G8IwDGGU2nA+VvwhqTP/0NLexDo0oMDu7Eo7fQkua1lumI= X-Received: by 2002:a05:6a20:3d0f:b0:174:1466:359c with SMTP id y15-20020a056a203d0f00b001741466359cmr2256045pzi.61.1697549790312; Tue, 17 Oct 2023 06:36:30 -0700 (PDT) In-Reply-To: <83jzrlo5au.fsf@gnu.org> 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:272608 Archived-At: --0000000000003d7d0e0607e99c4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=B2=D1=82, 17 =D0=BE=D0=BA=D1=82. 2023=E2=80=AF=D0=B3. =D0=B2 14:30, Eli= Zaretskii : > > From: Evgeny Zajcev > > Date: Tue, 17 Oct 2023 12:53:12 +0300 > > > > Just got crash with Emacs30 in the situation where Emacs 29 survives. > > I'm not sure I can reproduce this all the time > > Thanks, but I don't think I understand: if you cannot reproduce this, > then how do you know that Emacs 29 survives this non-reproducible > situation? > > I've been running Emacs29 in the same scenarios for a long time without abortions. I've started using Emacs30 couple of days ago, and got this abort just by working in Emacs as usual, that's why I think Emacs29 would survive. However, it might be some rare situation occurred and Emacs29 would also abort, I don't know And which Emacs 29 are we talking about -- Emacs 29.1 as released or > the current emacs-29 branch? > > I've been using GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) before moving to Emacs30 > Program terminated with signal SIGABRT, Aborted. > > #0 raise (sig=3D) at ../sysdeps/unix/sysv/linux/raise.c= :50 > > 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. > > [Current thread is 1 (Thread 0x7f76fdbd9080 (LWP 5095))] > > (gdb) bt > > #0 raise (sig=3D) at ../sysdeps/unix/sysv/linux/raise.c= :50 > > #1 0x000055ccdf18ad1e in terminate_due_to_signal (sig=3Dsig@entry=3D6, > > backtrace_limit=3Dbacktrace_limit@entry=3D40) at emacs.c:484 > > #2 0x000055ccdf18b262 in handle_fatal_signal (sig=3Dsig@entry=3D6) at > > sysdep.c:1801 > > #3 0x000055ccdf2e271d in deliver_thread_signal (sig=3D6, > > handler=3D0x55ccdf18b251 ) at sysdep.c:1793 > > #4 0x000055ccdf2e280f in deliver_fatal_thread_signal (sig=3D out>) > > at sysdep.c:1813 > > #5 0x00007f7701a593c0 in () at > > /lib/x86_64-linux-gnu/libpthread.so.0 > > #6 __GI_raise (sig=3Dsig@entry=3D6) at > ../sysdeps/unix/sysv/linux/raise.c:50 > > #7 0x00007f7701661859 in __GI_abort () at abort.c:79 > > #8 0x00007f77016cc3ee in __libc_message (action=3Daction@entry=3Ddo_ab= ort, > > fmt=3Dfmt@entry=3D0x7f77017f607c "*** %s ***: terminated\n") > > at ../sysdeps/posix/libc_fatal.c:155 > > #9 0x00007f770176eb4a in __GI___fortify_fail (msg=3Dmsg@entry > =3D0x7f77017f6012 > > "buffer overflow detected") at fortify_fail.c:26 > > #10 0x00007f770176d3e6 in __GI___chk_fail () at chk_fail.c:28 > > #11 0x00007f77016c41cf in _IO_str_chk_overflow (fp=3D, > > c=3D) at iovsprintf.c:35 > > #12 0x00007f77016d11a4 in __GI__IO_default_xsputn (n=3D, > > data=3D, f=3D) at libioP.h:948 > > #13 __GI__IO_default_xsputn (f=3D0x7ffef46bdc20, data=3D= , n=3D8) > > at genops.c:370 > > #14 0x00007f77016b692d in __vfprintf_internal > > (s=3Ds@entry=3D0x7ffef46bdc20, format=3Dformat@entry=3D0x55ccdf4184= 63 > "%0*X", > > ap=3Dap@entry=3D0x7ffef46bdd60, mode_flags=3Dmode_flags@entry=3D6) > > at ../libio/libioP.h:948 > > #15 0x00007f77016c4279 in __vsprintf_internal > > (string=3D0x7ffef46bdea1 "FFFC71", maxlen=3Dmaxlen@entry=3D7, > > format=3D0x55ccdf418463 "%0*X", args=3Dargs@entry=3D0x7ffef46bdd60, > > mode_flags=3Dmode_flags@entry=3D6) at iovsprintf.c:95 > > #16 0x00007f770176cedb in ___sprintf_chk > > (s=3Ds@entry=3D0x7ffef46bdea1 "FFFC71", flag=3Dflag@entry=3D1, > slen=3Dslen@entry=3D7, > > format=3Dformat@entry=3D0x55ccdf418463 "%0*X") at sprintf_chk.c:40 > > #17 0x000055ccdf1c312b in sprintf (__fmt=3D0x55ccdf418463 "%0*X", > > __s=3D0x7ffef46bdea1 "FFFC71") at > > /usr/include/x86_64-linux-gnu/bits/stdio2.h:36 > > #18 produce_glyphless_glyph (it=3D0x7ffef46c5660, > > for_no_font=3Dfor_no_font@entry=3Dfalse, acronym=3Dacronym@entry=3D0x0)= at > > xdisp.c:32165 > > This is abort, not a crash, and it's here: > > else > { > eassert (it->glyphless_method =3D=3D GLYPHLESS_DISPLAY_HEX_CODE= ); > sprintf (buf, "%0*X", it->c < 0x10000 ? 4 : 6, it->c + 0u); <<<= << > str =3D buf; > } > > Can you show the value of it->c in frame #18? > (gdb) up 18 #18 produce_glyphless_glyph (it=3D0x7ffef46c5660, for_no_font=3Dfor_no_font@entry=3Dfalse, acronym=3Dacronym@entry=3D0x0) at xdisp.c:32165 32165 sprintf (buf, "%0*X", it->c < 0x10000 ? 4 : 6, it->c + 0u); (gdb) p it->c $1 =3D -233054 (gdb) > > The abort happens inside libc, and I think the problem is that buf[7] > is not large enough for displaying hex code above 0xFFFF; we need > buf[8]. > --=20 lg --0000000000003d7d0e0607e99c4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=D0=B2=D1=82, 17 =D0=BE=D0=BA=D1=82.= 2023=E2=80=AF=D0=B3. =D0=B2 14:30, Eli Zaretskii <eliz@gnu.org>:
> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Tue, 17 Oct 2023 12:53:12 +0300
>
> Just got crash with Emacs30 in the situation where Emacs 29 survives.<= br> > I'm not sure I can reproduce this all the time

Thanks, but I don't think I understand: if you cannot reproduce this, then how do you know that Emacs 29 survives this non-reproducible
situation?


I've been running Emacs29 in the s= ame scenarios for a long time without abortions.
I've started= using Emacs30 couple of days ago, and got this abort just by working in Em= acs as usual,
that's why I think Emacs29 would survive.=C2=A0= However, it might be some rare situation occurred and Emacs29
wo= uld also abort, I don't know

And which Emacs 29 are we talking about -- Emacs 29.1 as released or
the current emacs-29 branch?


I've been using GNU Emacs 29.0.50 = (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) = before moving to Emacs30

> Program terminated with signal SIGABRT, Aborted.
> #0=C2=A0 raise (sig=3D<optimized out>) at ../sysdeps/unix/sysv/l= inux/raise.c:50
> 50=C2=A0 =C2=A0 =C2=A0 ../sysdeps/unix/sysv/linux/raise.c: No such fil= e or directory.
> [Current thread is 1 (Thread 0x7f76fdbd9080 (LWP 5095))]
> (gdb) bt
> #0=C2=A0 raise (sig=3D<optimized out>) at ../sysdeps/unix/sysv/l= inux/raise.c:50
> #1=C2=A0 0x000055ccdf18ad1e in terminate_due_to_signal (sig=3Dsig@entr= y=3D6,
> backtrace_limit=3Dbacktrace_limit@entry=3D40) at emacs.c:484
> #2=C2=A0 0x000055ccdf18b262 in handle_fatal_signal (sig=3Dsig@entry=3D= 6) at
> sysdep.c:1801
> #3=C2=A0 0x000055ccdf2e271d in deliver_thread_signal (sig=3D6,
> handler=3D0x55ccdf18b251 <handle_fatal_signal>) at sysdep.c:1793=
> #4=C2=A0 0x000055ccdf2e280f in deliver_fatal_thread_signal (sig=3D<= optimized out>)
> at sysdep.c:1813
> #5=C2=A0 0x00007f7701a593c0 in <signal handler called> () at
> /lib/x86_64-linux-gnu/libpthread.so.0
> #6=C2=A0 __GI_raise (sig=3Dsig@entry=3D6) at ../sysdeps/unix/sysv/linu= x/raise.c:50
> #7=C2=A0 0x00007f7701661859 in __GI_abort () at abort.c:79
> #8=C2=A0 0x00007f77016cc3ee in __libc_message (action=3Daction@entry= =3Ddo_abort,
> fmt=3Dfmt@entry=3D0x7f77017f607c "*** %s ***: terminated\n")=
>=C2=A0 =C2=A0 =C2=A0at ../sysdeps/posix/libc_fatal.c:155
> #9=C2=A0 0x00007f770176eb4a in __GI___fortify_fail (msg=3Dmsg@entry=3D= 0x7f77017f6012
> "buffer overflow detected") at fortify_fail.c:26
> #10 0x00007f770176d3e6 in __GI___chk_fail () at chk_fail.c:28
> #11 0x00007f77016c41cf in _IO_str_chk_overflow (fp=3D<optimized out= >,
> c=3D<optimized out>) at iovsprintf.c:35
> #12 0x00007f77016d11a4 in __GI__IO_default_xsputn (n=3D<optimized o= ut>,
> data=3D<optimized out>, f=3D<optimized out>) at libioP.h:9= 48
> #13 __GI__IO_default_xsputn (f=3D0x7ffef46bdc20, data=3D<optimized = out>, n=3D8)
> at genops.c:370
> #14 0x00007f77016b692d in __vfprintf_internal
>=C2=A0 =C2=A0 =C2=A0(s=3Ds@entry=3D0x7ffef46bdc20, format=3Dformat@entr= y=3D0x55ccdf418463 "%0*X",
> ap=3Dap@entry=3D0x7ffef46bdd60, mode_flags=3Dmode_flags@entry=3D6)
>=C2=A0 =C2=A0 =C2=A0at ../libio/libioP.h:948
> #15 0x00007f77016c4279 in __vsprintf_internal
>=C2=A0 =C2=A0 =C2=A0(string=3D0x7ffef46bdea1 "FFFC71", maxlen= =3Dmaxlen@entry=3D7,
> format=3D0x55ccdf418463 "%0*X", args=3Dargs@entry=3D0x7ffef4= 6bdd60,
> mode_flags=3Dmode_flags@entry=3D6) at iovsprintf.c:95
> #16 0x00007f770176cedb in ___sprintf_chk
>=C2=A0 =C2=A0 =C2=A0(s=3Ds@entry=3D0x7ffef46bdea1 "FFFC71", f= lag=3Dflag@entry=3D1, slen=3Dslen@entry=3D7,
> format=3Dformat@entry=3D0x55ccdf418463 "%0*X") at sprintf_ch= k.c:40
> #17 0x000055ccdf1c312b in sprintf (__fmt=3D0x55ccdf418463 "%0*X&q= uot;,
> __s=3D0x7ffef46bdea1 "FFFC71") at
> /usr/include/x86_64-linux-gnu/bits/stdio2.h:36
> #18 produce_glyphless_glyph (it=3D0x7ffef46c5660,
> for_no_font=3Dfor_no_font@entry=3Dfalse, acronym=3Dacronym@entry=3D0x0= ) at
> xdisp.c:32165

This is abort, not a crash, and it's here:

=C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 eassert (it->glyphless_method =3D=3D = GLYPHLESS_DISPLAY_HEX_CODE);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sprintf (buf, "%0*X", it->c= < 0x10000 ? 4 : 6, it->c + 0u); <<<<<
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 str =3D buf;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

Can you show the value of it->c in frame #18?

<= /div>
(gdb) up 18
#18 produce_glyphless_glyph (it=3D0x7ffef46c5660, = for_no_font=3Dfor_no_font@entry=3Dfalse, acronym=3Dacronym@entry=3D0x0) at = xdisp.c:32165
32165 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sprintf (b= uf, "%0*X", it->c < 0x10000 ? 4 : 6, it->c + 0u);
(gd= b) p it->c
$1 =3D -233054
(gdb)
=C2=A0

The abort happens inside libc, and I think the problem is that buf[7]
is not large enough for displaying hex code above 0xFFFF; we need
buf[8].

--
lg
--0000000000003d7d0e0607e99c4d--