GNU bug report logs - #66589
30.0.50; core dump in redisplay

Previous Next

Full log

Message #8 received at 66589 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Evgeny Zajcev <lg.zevlg <at> gmail.com>
Cc: 66589 <at> debbugs.gnu.org
Subject: Re: bug#66589: 30.0.50; core dump in redisplay
Date: Tue, 17 Oct 2023 14:29:45 +0300

> From: Evgeny Zajcev <lg.zevlg <at> 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?

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

> 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 <at> entry=6,
> backtrace_limit=backtrace_limit <at> entry=40) at emacs.c:484
> #2  0x000055ccdf18b262 in handle_fatal_signal (sig=sig <at> 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 <at> 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 <at> entry=do_abort,
> fmt=fmt <at> entry=0x7f77017f607c "*** %s ***: terminated\n")
>     at ../sysdeps/posix/libc_fatal.c:155
> #9  0x00007f770176eb4a in __GI___fortify_fail (msg=msg <at> 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 <at> entry=0x7ffef46bdc20, format=format <at> entry=0x55ccdf418463 "%0*X",
> ap=ap <at> entry=0x7ffef46bdd60, mode_flags=mode_flags <at> entry=6)
>     at ../libio/libioP.h:948
> #15 0x00007f77016c4279 in __vsprintf_internal
>     (string=0x7ffef46bdea1 "FFFC71", maxlen=maxlen <at> entry=7,
> format=0x55ccdf418463 "%0*X", args=args <at> entry=0x7ffef46bdd60,
> mode_flags=mode_flags <at> entry=6) at iovsprintf.c:95
> #16 0x00007f770176cedb in ___sprintf_chk
>     (s=s <at> entry=0x7ffef46bdea1 "FFFC71", flag=flag <at> entry=1, slen=slen <at> entry=7,
> format=format <at> 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 <at> entry=false, acronym=acronym <at> 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?

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].

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.