all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Evgeny Zajcev <lg.zevlg@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 66589@debbugs.gnu.org
Subject: bug#66589: 30.0.50; core dump in redisplay
Date: Tue, 17 Oct 2023 16:36:17 +0300	[thread overview]
Message-ID: <CAO=W_ZrBVKaSRMzc_P0m8+S2BNytxwNQqyGbZixekYErW9ogkw@mail.gmail.com> (raw)
In-Reply-To: <83jzrlo5au.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 4575 bytes --]

вт, 17 окт. 2023 г. в 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.
> > 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=<optimized out>) 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=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:50
> > #1  0x000055ccdf18ad1e in terminate_due_to_signal (sig=sig@entry=6,
> > backtrace_limit=backtrace_limit@entry=40) at emacs.c:484
> > #2  0x000055ccdf18b262 in handle_fatal_signal (sig=sig@entry=6) at
> > sysdep.c:1801
> > #3  0x000055ccdf2e271d in deliver_thread_signal (sig=6,
> > handler=0x55ccdf18b251 <handle_fatal_signal>) at sysdep.c:1793
> > #4  0x000055ccdf2e280f in deliver_fatal_thread_signal (sig=<optimized
> out>)
> > at sysdep.c:1813
> > #5  0x00007f7701a593c0 in <signal handler called> () at
> > /lib/x86_64-linux-gnu/libpthread.so.0
> > #6  __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:50
> > #7  0x00007f7701661859 in __GI_abort () at abort.c:79
> > #8  0x00007f77016cc3ee in __libc_message (action=action@entry=do_abort,
> > fmt=fmt@entry=0x7f77017f607c "*** %s ***: terminated\n")
> >     at ../sysdeps/posix/libc_fatal.c:155
> > #9  0x00007f770176eb4a in __GI___fortify_fail (msg=msg@entry
> =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=<optimized out>,
> > c=<optimized out>) at iovsprintf.c:35
> > #12 0x00007f77016d11a4 in __GI__IO_default_xsputn (n=<optimized out>,
> > data=<optimized out>, f=<optimized out>) at libioP.h:948
> > #13 __GI__IO_default_xsputn (f=0x7ffef46bdc20, data=<optimized out>, n=8)
> > at genops.c:370
> > #14 0x00007f77016b692d in __vfprintf_internal
> >     (s=s@entry=0x7ffef46bdc20, format=format@entry=0x55ccdf418463
> "%0*X",
> > ap=ap@entry=0x7ffef46bdd60, mode_flags=mode_flags@entry=6)
> >     at ../libio/libioP.h:948
> > #15 0x00007f77016c4279 in __vsprintf_internal
> >     (string=0x7ffef46bdea1 "FFFC71", maxlen=maxlen@entry=7,
> > format=0x55ccdf418463 "%0*X", args=args@entry=0x7ffef46bdd60,
> > mode_flags=mode_flags@entry=6) at iovsprintf.c:95
> > #16 0x00007f770176cedb in ___sprintf_chk
> >     (s=s@entry=0x7ffef46bdea1 "FFFC71", flag=flag@entry=1,
> slen=slen@entry=7,
> > format=format@entry=0x55ccdf418463 "%0*X") at sprintf_chk.c:40
> > #17 0x000055ccdf1c312b in sprintf (__fmt=0x55ccdf418463 "%0*X",
> > __s=0x7ffef46bdea1 "FFFC71") at
> > /usr/include/x86_64-linux-gnu/bits/stdio2.h:36
> > #18 produce_glyphless_glyph (it=0x7ffef46c5660,
> > for_no_font=for_no_font@entry=false, acronym=acronym@entry=0x0) at
> > xdisp.c:32165
>
> This is abort, not a crash, and it's here:
>
>       else
>         {
>           eassert (it->glyphless_method == GLYPHLESS_DISPLAY_HEX_CODE);
>           sprintf (buf, "%0*X", it->c < 0x10000 ? 4 : 6, it->c + 0u); <<<<<
>           str = buf;
>         }
>
> Can you show the value of it->c in frame #18?
>

(gdb) up 18
#18 produce_glyphless_glyph (it=0x7ffef46c5660,
for_no_font=for_no_font@entry=false, acronym=acronym@entry=0x0) at
xdisp.c:32165
32165             sprintf (buf, "%0*X", it->c < 0x10000 ? 4 : 6, it->c +
0u);
(gdb) p it->c
$1 = -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].
>

-- 
lg

[-- Attachment #2: Type: text/html, Size: 6152 bytes --]

  parent reply	other threads:[~2023-10-17 13:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-17  9:53 bug#66589: 30.0.50; core dump in redisplay Evgeny Zajcev
2023-10-17 11:29 ` Eli Zaretskii
2023-10-17 12:34   ` Gerd Möllmann
2023-10-17 13:36   ` Evgeny Zajcev [this message]
2023-10-17 15:01     ` Eli Zaretskii
2023-10-17 15:11       ` Evgeny Zajcev
2023-10-17 15:14         ` Evgeny Zajcev
2023-10-17 17:59         ` Eli Zaretskii
2023-10-17 18:11           ` Evgeny Zajcev
2023-10-17 19:23             ` Eli Zaretskii
2023-10-17 19:34               ` Evgeny Zajcev
2023-10-17 19:37                 ` Evgeny Zajcev
2023-10-18 11:40                   ` Eli Zaretskii
2024-03-11 10:26                     ` Florian Weimer
2024-03-11 13:21                       ` Eli Zaretskii
2024-03-11 15:32                         ` Evgeny Zajcev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO=W_ZrBVKaSRMzc_P0m8+S2BNytxwNQqyGbZixekYErW9ogkw@mail.gmail.com' \
    --to=lg.zevlg@gmail.com \
    --cc=66589@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.