bug#52141: 29.0.50; Crash during redisplay

bug#52141: 29.0.50; Crash during redisplay

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

I was typing a random document to test something, and I got the
following crash out of the blue:

#0  0x00007f201abbc85c in __pthread_kill_implementation () at /lib64/libc.so.6
#1  0x00007f201ab6f6b6 in raise () at /lib64/libc.so.6
#2  0x000000000041b6aa in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:443
#3  0x000000000041bb29 in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1780
#4  0x000000000051b9d8 in deliver_thread_signal (sig=sig@entry=11, handler=0x41bb1e <handle_fatal_signal>) at sysdep.c:1772
#5  0x000000000051ba49 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1792
#6  handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1885
#7  0x00007f201ab6f760 in <signal handler called> () at /lib64/libc.so.6
#8  0x000000000055c6b1 in make_lisp_ptr (type=<optimized out>, ptr=<optimized out>)
    at /home/oldosfan/emacs-dev/emacs-gc/src/lisp.h:1269
#9  set_next_vectorPython Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0xfe94cc8
 (p=#10 setup_on_free_list (nbytes=<optimized out>, v=0x2ce6c10) at alloc.c:2977
#11 sweep_vectors () at alloc.c:3242
#12 0x0000000000561328 in gc_sweep () at alloc.c:7255
#13 garbage_collect () at alloc.c:6190
#14 0x0000000000561811 in maybe_garbage_collect () at alloc.c:6053
#15 0x00000000005804ad in maybe_gc () at /home/oldosfan/emacs-dev/emacs-gc/src/lisp.h:5161
#16 eval_sub (form=0x1e753d3) at eval.c:2449
#17 0x0000000000582149 in Feval (form=0x1e753d3, lexical=<optimized out>) at eval.c:2372
#18 0x000000000057d264 in internal_condition_case_1
    (bfun=bfun@entry=0x503480 <eval_dyn>, arg=arg@entry=0x1e753d3, handlers=handlers@entry=0x90, hfun=hfun@entry=0x504110 <menu_item_eval_property_1>) at eval.c:1519
#19 0x000000000050bbd4 in menu_item_eval_property (sexpr=0x1e753d3) at keyboard.c:7705
#20 0x000000000050c7ad in parse_tool_bar_item (item=<optimized out>, key=0x7f2018e45708) at keyboard.c:8645
#21 process_tool_bar_item (key=0x7f2018e45708, def=<optimized out>, data=data@entry=0x0, args=args@entry=0x0)
    at keyboard.c:8525
#22 0x0000000000516c3e in map_keymap_item
    (data=0x0, val=<optimized out>, key=<optimized out>, args=0x0, fun=0x50c080 <process_tool_bar_item>) at keymap.c:507
#23 map_keymap_internal
    (map=map@entry=0x211e0d3, fun=fun@entry=0x50c080 <process_tool_bar_item>, args=args@entry=0x0, data=data@entry=0x0)
    at keymap.c:554
#24 0x0000000000517dd3 in map_keymap
    (map=0x211e0d3, fun=fun@entry=0x50c080 <process_tool_bar_item>, args=args@entry=0x0, data=data@entry=0x0, autoload=autoload@entry=true) at keymap.c:599
#25 0x000000000050d69c in tool_bar_items (reuse=<optimized out>, nitems=nitems@entry=0x7ffe6054cbcc) at keyboard.c:8489
#26 0x000000000043b831 in update_tool_bar (f=f@entry=0x1fd42e0, save_match_data=save_match_data@entry=false) at xdisp.c:14357
#27 0x00000000004696e1 in update_tool_bar (save_match_data=false, f=0x1fd42e0) at xdisp.c:14301
#28 prepare_menu_bars () at xdisp.c:13180
#29 redisplay_internal () at xdisp.c:16008
#30 0x000000000050eafb in read_char
    (commandflag=1, map=0x2e32f43, prev_event=0x0, used_mouse_menu=0x7ffe6054e5bb, end_time=0x0) at keyboard.c:2923
#31 0x0000000000510f11 in read_key_sequence
    (keybuf=<optimized out>, prompt=0x0, dont_downcase_last=<optimized out>, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<optimized out>) at keyboard.c:9616
#32 0x000000000051289e in command_loop_1 () at keyboard.c:1393
#33 0x000000000057d1d7 in internal_condition_case
    (bfun=bfun@entry=0x5126c0 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x509130 <cmd_error>)
    at eval.c:1495
#34 0x000000000050345a in command_loop_2 (handlers=handlers@entry=0x90) at keyboard.c:1134
#35 0x000000000057d131 in internal_catch (tag=tag@entry=0xe9a0, func=func@entry=0x503440 <command_loop_2>, arg=arg@entry=0x90)
    at eval.c:1226
#36 0x00000000005033ff in command_loop () at keyboard.c:1112
#37 0x0000000000508d2c in recursive_edit_1 () at keyboard.c:721
#38 0x0000000000509073 in Frecursive_edit () at keyboard.c:804
#39 0x00000000004234ff in main (argc=2, argv=<optimized out>) at emacs.c:2409

Please let me know if you need any more information and/or core dumps,
thanks.

In GNU Emacs 29.0.50 (build 338, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2021-11-27 built on sofa
Repository revision: 6072370db7244a13470252e5369c4c9de3e3a9ef
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Fedora Linux 35 (Workstation Edition)

Configured using:
 'configure --with-x-toolkit=lucid --without-cairo --with-xinput2
 --cache-file=/tmp/ccache'

Configured features:
ACL DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LCMS2
LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG
SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XAW3D XDBE XFT
XIM XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
epg-config gnus-util rmail rmail-loaddefs auth-source cl-seq eieio
eieio-core cl-macs eieio-loaddefs password-cache json map
text-property-search time-date seq gv subr-x byte-opt bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils help-mode cl-loaddefs cl-lib iso-transl
tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget keymap hashtable-print-readable backquote threads
dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 56115 8055)
 (symbols 48 6793 1)
 (strings 32 22189 1464)
 (string-bytes 1 707304)
 (vectors 16 14078)
 (vector-slots 8 188048 8894)
 (floats 8 24 46)
 (intervals 56 240 0)
 (buffers 992 10))

bug#52141: 29.0.50; Crash during redisplay

[Eli Zaretskii]

> Date: Sat, 27 Nov 2021 19:03:06 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> I was typing a random document to test something, and I got the
> following crash out of the blue:
> 
> #0  0x00007f201abbc85c in __pthread_kill_implementation () at /lib64/libc.so.6
> #1  0x00007f201ab6f6b6 in raise () at /lib64/libc.so.6
> #2  0x000000000041b6aa in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:443
> #3  0x000000000041bb29 in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1780
> #4  0x000000000051b9d8 in deliver_thread_signal (sig=sig@entry=11, handler=0x41bb1e <handle_fatal_signal>) at sysdep.c:1772
> #5  0x000000000051ba49 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1792
> #6  handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1885
> #7  0x00007f201ab6f760 in <signal handler called> () at /lib64/libc.so.6
> #8  0x000000000055c6b1 in make_lisp_ptr (type=<optimized out>, ptr=<optimized out>)
>     at /home/oldosfan/emacs-dev/emacs-gc/src/lisp.h:1269
> #9  set_next_vectorPython Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0xfe94cc8
>  (p=#10 setup_on_free_list (nbytes=<optimized out>, v=0x2ce6c10) at alloc.c:2977
> #11 sweep_vectors () at alloc.c:3242
> #12 0x0000000000561328 in gc_sweep () at alloc.c:7255
> #13 garbage_collect () at alloc.c:6190
> #14 0x0000000000561811 in maybe_garbage_collect () at alloc.c:6053
> #15 0x00000000005804ad in maybe_gc () at /home/oldosfan/emacs-dev/emacs-gc/src/lisp.h:5161
> #16 eval_sub (form=0x1e753d3) at eval.c:2449
> #17 0x0000000000582149 in Feval (form=0x1e753d3, lexical=<optimized out>) at eval.c:2372
                                   ^^^^
What is this form we are evaluating here?  Can you show its contents?
(Not that I think it is related to the crash.)

Basically, GC was triggered by that evaluation, and it found some bad
memory in some vector that it wanted to put on the free list.  The
challenge is to determine which Lisp vector caused that bad memory.
Try looking at the data in frames 10 and 9 to figure out what was that
bad vector.

bug#52141: 29.0.50; Crash during redisplay

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 27 Nov 2021 19:03:06 +0800
>> From:  Po Lu via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> 
>> I was typing a random document to test something, and I got the
>> following crash out of the blue:
>> 
>> #0  0x00007f201abbc85c in __pthread_kill_implementation () at /lib64/libc.so.6
>> #1  0x00007f201ab6f6b6 in raise () at /lib64/libc.so.6
>> #2  0x000000000041b6aa in terminate_due_to_signal (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40) at emacs.c:443
>> #3  0x000000000041bb29 in handle_fatal_signal (sig=sig@entry=11) at sysdep.c:1780
>> #4  0x000000000051b9d8 in deliver_thread_signal (sig=sig@entry=11, handler=0x41bb1e <handle_fatal_signal>) at sysdep.c:1772
>> #5  0x000000000051ba49 in deliver_fatal_thread_signal (sig=11) at sysdep.c:1792
>> #6  handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at sysdep.c:1885
>> #7  0x00007f201ab6f760 in <signal handler called> () at /lib64/libc.so.6
>> #8  0x000000000055c6b1 in make_lisp_ptr (type=<optimized out>, ptr=<optimized out>)
>>     at /home/oldosfan/emacs-dev/emacs-gc/src/lisp.h:1269
>> #9  set_next_vectorPython Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0xfe94cc8
>>  (p=#10 setup_on_free_list (nbytes=<optimized out>, v=0x2ce6c10) at alloc.c:2977
>> #11 sweep_vectors () at alloc.c:3242
>> #12 0x0000000000561328 in gc_sweep () at alloc.c:7255
>> #13 garbage_collect () at alloc.c:6190
>> #14 0x0000000000561811 in maybe_garbage_collect () at alloc.c:6053
>> #15 0x00000000005804ad in maybe_gc () at /home/oldosfan/emacs-dev/emacs-gc/src/lisp.h:5161
>> #16 eval_sub (form=0x1e753d3) at eval.c:2449
>> #17 0x0000000000582149 in Feval (form=0x1e753d3, lexical=<optimized out>) at eval.c:2372
>                                    ^^^^
> What is this form we are evaluating here?  Can you show its contents?
> (Not that I think it is related to the crash.)

Its type is Lisp_Cons.  However, its address is invalid.  Running
`xcons' in gdb complains:

(gdb) xcons
$9 = (struct Lisp_Cons *) 0x1e753d0
Cannot access memory at address 0x1e753d0

Thanks.

bug#52141: 29.0.50; Crash during redisplay

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: 52141@debbugs.gnu.org
> Date: Sat, 27 Nov 2021 19:32:29 +0800
> 
> >> #9  set_next_vectorPython Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0xfe94cc8
> >>  (p=#10 setup_on_free_list (nbytes=<optimized out>, v=0x2ce6c10) at alloc.c:2977
> >> #11 sweep_vectors () at alloc.c:3242
> >> #12 0x0000000000561328 in gc_sweep () at alloc.c:7255
> >> #13 garbage_collect () at alloc.c:6190
> >> #14 0x0000000000561811 in maybe_garbage_collect () at alloc.c:6053
> >> #15 0x00000000005804ad in maybe_gc () at /home/oldosfan/emacs-dev/emacs-gc/src/lisp.h:5161
> >> #16 eval_sub (form=0x1e753d3) at eval.c:2449
> >> #17 0x0000000000582149 in Feval (form=0x1e753d3, lexical=<optimized out>) at eval.c:2372
> >                                    ^^^^
> > What is this form we are evaluating here?  Can you show its contents?
> > (Not that I think it is related to the crash.)
> 
> Its type is Lisp_Cons.  However, its address is invalid.  Running
> `xcons' in gdb complains:
> 
> (gdb) xcons
> $9 = (struct Lisp_Cons *) 0x1e753d0
> Cannot access memory at address 0x1e753d0

Hmm... and the address is very different from the one which caused the
segfault.  Strange.

Any ideas, anyone?

bug#52141: 29.0.50; Crash during redisplay

[Andreas Schwab]

On Nov 27 2021, Eli Zaretskii wrote:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: 52141@debbugs.gnu.org
>> Date: Sat, 27 Nov 2021 19:32:29 +0800
>> 
>> >> #9  set_next_vectorPython Exception <class 'gdb.MemoryError'>: Cannot access memory at address 0xfe94cc8
>> >>  (p=#10 setup_on_free_list (nbytes=<optimized out>, v=0x2ce6c10) at alloc.c:2977
>> >> #11 sweep_vectors () at alloc.c:3242
>> >> #12 0x0000000000561328 in gc_sweep () at alloc.c:7255
>> >> #13 garbage_collect () at alloc.c:6190
>> >> #14 0x0000000000561811 in maybe_garbage_collect () at alloc.c:6053
>> >> #15 0x00000000005804ad in maybe_gc () at /home/oldosfan/emacs-dev/emacs-gc/src/lisp.h:5161
>> >> #16 eval_sub (form=0x1e753d3) at eval.c:2449
>> >> #17 0x0000000000582149 in Feval (form=0x1e753d3, lexical=<optimized out>) at eval.c:2372
>> >                                    ^^^^
>> > What is this form we are evaluating here?  Can you show its contents?
>> > (Not that I think it is related to the crash.)
>> 
>> Its type is Lisp_Cons.  However, its address is invalid.  Running
>> `xcons' in gdb complains:
>> 
>> (gdb) xcons
>> $9 = (struct Lisp_Cons *) 0x1e753d0
>> Cannot access memory at address 0x1e753d0
>
> Hmm... and the address is very different from the one which caused the
> segfault.  Strange.

There could have been several corruptions that only surfaced just now.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#52141: 29.0.50; Crash during redisplay

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> 
>> Its type is Lisp_Cons.  However, its address is invalid.  Running
>> `xcons' in gdb complains:
>> 
>> (gdb) xcons
>> $9 = (struct Lisp_Cons *) 0x1e753d0
>> Cannot access memory at address 0x1e753d0
>
> Hmm... and the address is very different from the one which caused the
> segfault.  Strange.
>
> Any ideas, anyone?

Is it possible to run that Emacs instance with some kind of memory
sanitizer enabled (ASAN, Valgrind...)?  That may help catch the
potential memory corruption at the point it happens, not at the point
the garbage collector wants to free it.

bug#52141: 29.0.50; Crash during redisplay

[Eli Zaretskii]

> From: Daniel Martín <mardani29@yahoo.es>
> Cc: Po Lu <luangruo@yahoo.com>,  52141@debbugs.gnu.org
> Date: Sat, 27 Nov 2021 16:59:16 +0100
> 
> Is it possible to run that Emacs instance with some kind of memory
> sanitizer enabled (ASAN, Valgrind...)?  That may help catch the
> potential memory corruption at the point it happens, not at the point
> the garbage collector wants to free it.

It's possible, see etc/DEBUG.  But it may not be practical, since at
least Valgrind slows down Emacs tremendously.  But if this will happen
frequently enough, it's worth the try.

bug#52141: 29.0.50; Crash during redisplay

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Daniel Martín <mardani29@yahoo.es> writes:

> Is it possible to run that Emacs instance with some kind of memory
> sanitizer enabled (ASAN, Valgrind...)?  That may help catch the
> potential memory corruption at the point it happens, not at the point
> the garbage collector wants to free it.

I don't know how to reproduce this bug, so I don't think Valgrind will
work well.

But I will run a build with asan for a few days, thanks.