all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#66589: 30.0.50; core dump in redisplay
@ 2023-10-17  9:53 Evgeny Zajcev
  2023-10-17 11:29 ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Evgeny Zajcev @ 2023-10-17  9:53 UTC (permalink / raw)
  To: 66589

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

Just got crash with Emacs30 in the situation where Emacs 29 survives.
I'm not sure I can reproduce this all the time

[lg@x1:~/dev/emacs-30]$ gdb src/emacs core
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from src/emacs...
[New LWP 5095]
[New LWP 5098]
[New LWP 5100]
[New LWP 5099]
[New LWP 5101]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `src/emacs'.
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
#19 0x000055ccdf1eb141 in gui_produce_glyphs (it=0x7ffef46c5660) at
lisp.h:1179
#20 0x000055ccdf1ce5b4 in move_it_in_display_line_to
    (it=it@entry=0x7ffef46c5660, to_charpos=to_charpos@entry=10106,
to_x=to_x@entry=-1, op=op@entry=MOVE_TO_POS) at xdisp.c:9937
#21 0x000055ccdf1d38c8 in move_it_to
    (it=0x7ffef46c5660, to_charpos=10106, to_x=<optimized out>,
to_y=<optimized out>, to_vpos=<optimized out>, op=11) at xdisp.c:10558
#22 0x000055ccdf1fd463 in redisplay_window (window=0x55ccede844cd,
just_this_one_p=<optimized out>) at xdisp.c:19974
#23 0x000055ccdf1ff0b3 in redisplay_window_0
(window=window@entry=0x55ccede844cd)
at xdisp.c:17829
#24 0x000055ccdf34f23c in internal_condition_case_1
    (bfun=bfun@entry=0x55ccdf1ff080 <redisplay_window_0>,
arg=arg@entry=0x55ccede844cd,
handlers=<optimized out>, hfun=hfun@entry=0x55ccdf1b4450
<redisplay_window_error>) at eval.c:1510
#25 0x000055ccdf1b07d9 in redisplay_windows (window=0x55ccede844cd) at
xdisp.c:17798
#26 0x000055ccdf1b07fd in redisplay_windows (window=0x55ccf2b8e8ed) at
xdisp.c:17792
#27 0x000055ccdf1e6391 in redisplay_internal () at xdisp.c:17198
#28 0x000055ccdf1e7a58 in redisplay_preserve_echo_area
(from_where=from_where@entry=12) at xdisp.c:17557
#29 0x000055ccdf3a9402 in wait_reading_process_output
    (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0,
read_kbd=read_kbd@entry=-1, do_display=<optimized out>,
wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0,
just_wait_proc=<optimized out>) at process.c:5937
#30 0x000055ccdf2cb735 in kbd_buffer_get_event (end_time=0x0,
used_mouse_menu=0x7ffef46c9e4b, kbp=<synthetic pointer>) at lisp.h:1179
#31 read_event_from_main_queue (used_mouse_menu=0x7ffef46c9e4b,
local_getcjmp=0x7ffef46c9ba0, end_time=0x0) at keyboard.c:2309
#32 read_decoded_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7ffef46c9ba0, prev_event=0x0,
used_mouse_menu=0x7ffef46c9e4b)
    at keyboard.c:2373
#33 0x000055ccdf2d19dc in read_char (commandflag=1, map=0x55ccf2614e43,
prev_event=0x0, used_mouse_menu=0x7ffef46c9e4b, end_time=0x0)
    at keyboard.c:3003
#34 0x000055ccdf2d3a90 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>, disable_text_conversion_p=false) at
keyboard.c:10617
#35 0x000055ccdf2d5c26 in command_loop_1 () at lisp.h:1179
#36 0x000055ccdf34f1a7 in internal_condition_case
    (bfun=bfun@entry=0x55ccdf2d5a50 <command_loop_1>,
handlers=handlers@entry=0x90, hfun=hfun@entry=0x55ccdf2c8010 <cmd_error>)
at eval.c:1486
#37 0x000055ccdf2c05fa in command_loop_2 (handlers=handlers@entry=0x90) at
keyboard.c:1157
#38 0x000055ccdf34f0e9 in internal_catch (tag=tag@entry=0x6e10,
func=func@entry=0x55ccdf2c05d0 <command_loop_2>, arg=arg@entry=0x90)
    at eval.c:1209
#39 0x000055ccdf2c054c in command_loop () at lisp.h:1179
#40 0x000055ccdf2c7b47 in recursive_edit_1 () at keyboard.c:744
#41 0x000055ccdf2c7f14 in Frecursive_edit () at keyboard.c:827
#42 0x000055ccdf39c872 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at lisp.h:2210
#43 0x000055ccdf3509f0 in Ffuncall (nargs=3, args=0x7ffef46ca270) at
eval.c:3008
#44 0x000055ccdf350df8 in Fapply (nargs=nargs@entry=2,
args=args@entry=0x7ffef46ca320)
at eval.c:2679
#45 0x000055ccdf351110 in apply1 (fn=<optimized out>,
arg=arg@entry=0x55ccf25a3e73)
at lisp.h:1480
#46 0x000055ccdf351242 in call_debugger (arg=0x55ccf25a3e73) at eval.c:315
#47 0x000055ccdf351f54 in maybe_call_debugger (data=0x55ccf25a3ea3,
sig=0x12840, conditions=<optimized out>) at lisp.h:1179
#48 signal_or_quit (error_symbol=0x12840, data=0x55ccf25a3ea3,
keyboard_quit=<optimized out>) at eval.c:1800
#49 0x000055ccdf18d6dd in Fsignal (error_symbol=<optimized out>,
error_symbol@entry=0x12840, data=<optimized out>) at eval.c:1697
#50 0x000055ccdf18d8b5 in xsignal (data=<optimized out>,
error_symbol=0x12840) at lisp.h:4569
#51 xsignal2 (error_symbol=error_symbol@entry=0x12840, arg1=arg1@entry=0xcd20,
arg2=<optimized out>) at eval.c:1896
#52 0x000055ccdf18c86d in wrong_type_argument
(predicate=predicate@entry=0xcd20,
value=<optimized out>) at lisp.h:1179
#53 0x000055ccdf18c887 in CHECK_TYPE (x=<optimized out>, predicate=0xcd20,
ok=0) at lisp.h:807
#54 check_number_coerce_marker (x=<optimized out>) at data.c:2636
#55 0x000055ccdf33bf52 in arithcompare (num1=<optimized out>,
num2=0x190b65400002, comparison=comparison@entry=ARITH_EQUAL) at data.c:2648
#56 0x000055ccdf39e414 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:1248
#57 0x000055ccdf3509f0 in Ffuncall (nargs=3, args=0x7ffef46ca590) at
eval.c:3008
#58 0x000055ccdf350df8 in Fapply (nargs=2, args=0x7f76fc5ed0a0) at
eval.c:2679
#59 0x000055ccdf39c872 in exec_byte_code (fun=<optimized out>,
args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at lisp.h:2210
#60 0x000055ccdf3509f0 in Ffuncall (nargs=3, args=0x7ffef46ca700) at
eval.c:3008
#61 0x000055ccdf350df8 in Fapply (nargs=nargs@entry=2,
args=args@entry=0x7ffef46ca7b0)
at eval.c:2679
#62 0x000055ccdf351110 in apply1 (fn=<optimized out>, arg=<optimized out>)
at lisp.h:1480
#63 0x000055ccdf34f23c in internal_condition_case_1
    (bfun=bfun@entry=0x55ccdf39f8c0 <read_process_output_call>,
arg=0x55ccf25a5353, handlers=handlers@entry=0x0, hfun=hfun@entry=0x55ccdf39f800
<read_process_output_error_handler>) at eval.c:1510
#64 0x000055ccdf3a335b in read_and_dispose_of_process_output
    (coding=0x55cce49fb920, nbytes=2206, chars=0x7ffef46ca810 "event
1494\n(:@type \"updateMessageInteractionInfo\" :chat_id -1001576781132
:message_id 6884681580544 :interaction_info (:@type
\"messageInteractionInfo\" :view_count 15118 :forward_count 10 :reply_info
("..., p=0x7ffef46cb8db)
    at lisp.h:1367
#65 read_process_output (proc=proc@entry=0x55ccec4a617d,
channel=channel@entry=27) at process.c:6236
#66 0x000055ccdf3a93b7 in wait_reading_process_output
    (time_limit=time_limit@entry=0, nsecs=nsecs@entry=0,
read_kbd=read_kbd@entry=-1, do_display=<optimized out>,
wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0,
just_wait_proc=<optimized out>) at process.c:5920
#67 0x000055ccdf2cb735 in kbd_buffer_get_event (end_time=0x0,
used_mouse_menu=0x7ffef46cc51b, kbp=<synthetic pointer>) at lisp.h:1179
#68 read_event_from_main_queue (used_mouse_menu=0x7ffef46cc51b,
local_getcjmp=0x7ffef46cc270, end_time=0x0) at keyboard.c:2309
#69 read_decoded_event_from_main_queue (end_time=0x0,
local_getcjmp=0x7ffef46cc270, prev_event=0x0,
used_mouse_menu=0x7ffef46cc51b)
    at keyboard.c:2373
#70 0x000055ccdf2d19dc in read_char (commandflag=1, map=0x55ccf172cc23,
prev_event=0x0, used_mouse_menu=0x7ffef46cc51b, end_time=0x0)
    at keyboard.c:3003
#71 0x000055ccdf2d3a90 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>, disable_text_conversion_p=false) at
keyboard.c:10617
#72 0x000055ccdf2d5c26 in command_loop_1 () at lisp.h:1179
#73 0x000055ccdf34f1a7 in internal_condition_case
    (bfun=bfun@entry=0x55ccdf2d5a50 <command_loop_1>,
handlers=handlers@entry=0x90, hfun=hfun@entry=0x55ccdf2c8010 <cmd_error>)
at eval.c:1486
#74 0x000055ccdf2c05fa in command_loop_2 (handlers=handlers@entry=0x90) at
keyboard.c:1157
#75 0x000055ccdf34f0e9 in internal_catch (tag=tag@entry=0x10860,
func=func@entry=0x55ccdf2c05d0 <command_loop_2>, arg=arg@entry=0x90)
    at eval.c:1209
#76 0x000055ccdf2c0596 in command_loop () at lisp.h:1179
#77 0x000055ccdf2c7b47 in recursive_edit_1 () at keyboard.c:744
#78 0x000055ccdf2c7f14 in Frecursive_edit () at keyboard.c:827
#79 0x000055ccdf1936e3 in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:2625
(gdb)

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.20, cairo version 1.16.0) of 2023-10-12 built on x1
Repository revision: 963ccc05acf2939c95524de9175a1fc3053b0f6f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12009000
System Description: Ubuntu 20.04.1 LTS

Configured using:
 'configure --with-modules --with-xwidgets --with-tree-sitter'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM
XINPUT2 XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: ru_RU.UTF-8
  value of $LC_NUMERIC: ru_RU.UTF-8
  value of $LC_TIME: ru_RU.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: VTerm

Minor modes in effect:
  buffer-face-mode: t
  reverse-im-mode: t
  desktop-save-mode: t
  pyvenv-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  global-paren-face-mode: t
  which-function-mode: t
  save-place-mode: t
  server-mode: t
  global-undo-tree-mode: t
  icomplete-mode: t
  disable-mouse-global-mode: t
  override-global-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
~/github/eukleides.el/eukleides hides ~/github/emacs-stuff/eukleides
/home/lg/.emacs.d/elpa/magit-20210327.1617/magit-section hides
/home/lg/.emacs.d/elpa/magit-section-20210702.822/magit-section
~/dev/emacs-libvterm/vterm hides
/home/lg/.emacs.d/elpa/vterm-20210326.1458/vterm
/home/lg/.emacs.d/elpa/bind-key-20210210.1609/bind-key hides
/home/lg/dev/emacs-30/lisp/bind-key
/home/lg/.emacs.d/elpa/transient-20230315.1520/transient hides
/home/lg/dev/emacs-30/lisp/transient
/home/lg/.emacs.d/elpa/use-package-20210207.1926/use-package-diminish hides
/home/lg/dev/emacs-30/lisp/use-package/use-package-diminish
/home/lg/.emacs.d/elpa/use-package-20210207.1926/use-package-delight hides
/home/lg/dev/emacs-30/lisp/use-package/use-package-delight
/home/lg/.emacs.d/elpa/use-package-20210207.1926/use-package-bind-key hides
/home/lg/dev/emacs-30/lisp/use-package/use-package-bind-key
/home/lg/.emacs.d/elpa/use-package-20210207.1926/use-package-ensure hides
/home/lg/dev/emacs-30/lisp/use-package/use-package-ensure
/home/lg/.emacs.d/elpa/use-package-20210207.1926/use-package hides
/home/lg/dev/emacs-30/lisp/use-package/use-package
/home/lg/.emacs.d/elpa/use-package-20210207.1926/use-package-core hides
/home/lg/dev/emacs-30/lisp/use-package/use-package-core
/home/lg/.emacs.d/elpa/use-package-20210207.1926/use-package-lint hides
/home/lg/dev/emacs-30/lisp/use-package/use-package-lint
/home/lg/.emacs.d/elpa/use-package-20210207.1926/use-package-jump hides
/home/lg/dev/emacs-30/lisp/use-package/use-package-jump
/home/lg/.emacs.d/elpa/use-package-ensure-system-package-20180913.1501/use-package-ensure-system-package
hides
/home/lg/dev/emacs-30/lisp/use-package/use-package-ensure-system-package

Features:
(shadow sort mail-extr markdown-mode emacsbug protobuf-mode cc-langs
make-mode mule-util mhtml-mode css-mode js sgml-mode facemenu
company-org-block org-indent org-element org-persist org-id org-refile
avl-tree oc-basic ol-eww eww url-queue mm-url ol-rmail ol-mhe ol-irc
ol-info ol-gnus nnselect gnus-art mm-uu mml2015 mm-view mml-smime smime
gnutls dig gnus-sum shr pixel-fill kinsoku url-file svg dom ol-docview
doc-view jka-compr ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi
image-converter image-mode exif flycheck conf-mode vterm magit-bookmark
bookmark face-remap term disp-table ehelp vterm-module term/xterm xterm
macrostep-c cmacexp macrostep c++-ts-mode c-ts-mode c-ts-common cc-mode
cc-fonts cc-guess cc-menus cc-styles cc-align vc-git company-keywords
company-dabbrev-code company-dabbrev company-files company-clang
company-template company-cmake reverse-im avy quail dockerfile-mode
sh-script smie executable dashboard dashboard-widgets all-the-icons
all-the-icons-faces data-material data-weathericons data-octicons
data-fileicons data-faicons data-alltheicons recentf tree-widget home
lichess lichess-runtime lichess-api lichess-util sound-wav deferred
request cider cider-debug cider-browse-ns cider-mode cider-inspector
cider-completion cider-profile cider-eval cider-repl-history pulse
cider-repl cider-resolve cider-test cider-overlays cider-stacktrace
cider-doc cider-browse-spec cider-clojuredocs cider-eldoc cider-client
cider-common cider-connection cider-util cider-popup sesman-browser
nrepl-client queue nrepl-dict cider-compat spinner sesman vc
vc-dispatcher clojure-mode lisp-mnt align parseedn parseclj-parser
parseclj-lex a desktop frameset gnus-demon nntp gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7
gnus-spec gnus-win nnoo gnus-int gnus-range gnus nnheader range
autoinsert cython-mode company-capf company-posframe posframe company
help-fns radix-tree elpy elpy-rpc pyvenv eshell esh-cmd esh-ext esh-opt
esh-proc esh-io esh-arg esh-module esh-groups esh-util elpy-shell
elpy-profile elpy-django elpy-refactor python treesit etags fileloop
generator xref cus-edit cus-load wid-edit python-mode info-look hideshow
hippie-exp flymake project warnings thingatpt ert pp ewoc debug
backtrace cc-cmds cc-engine cc-vars cc-defs magit-todos pcre2el rxt
pcase re-builder magit-submodule magit-obsolete magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit magit-repos magit-apply magit-wip magit-log
magit-diff smerge-mode diff-mode git-commit log-edit message sendmail
yank-media rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util mm-decode mm-bodies mm-encode mailabbrev mail-utils gmm-utils
mailheader pcvs-util add-log magit-core magit-autorevert autorevert
filenotify magit-margin magit-transient magit-process with-editor
magit-mode transient compat magit-git magit-section magit-utils crm
hl-todo f s dash async grep compile text-property-search paren-face
dot-mode which-func imenu gist-org saveplace tramp-sh tramp trampver
tramp-integration files-x tramp-message tramp-compat xdg shell
parse-time iso8601 tramp-loaddefs gist dired dired-loaddefs gh-gist
gh-oauth gh-api logito gh-cache pcache gh-auth gh-common marshal gh-url
url-http url-auth mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr url-gw nsm puny gh-profile timezone eieio-base server time
google-translate google-translate-default-ui google-translate-core-ui
color popup google-translate-core google-translate-tk
google-translate-backend whitespace undo-tree diff ido icomplete avoid
disable-mouse page-break-lines ibuffer-vc ibuf-ext ibuffer
ibuffer-loaddefs org-bullets org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro org-src ob-comint org-pcomplete pcomplete comint
ansi-osc ansi-color ring org-list org-footnote org-faces org-entities
time-date noutline outline icons ob-emacs-lisp ob-core ob-eval org-cycle
org-table ol org-fold org-fold-core org-keys oc org-loaddefs find-func
cal-menu calendar cal-loaddefs org-version org-compat org-macs
format-spec edmacro kmacro advice browse-kill-ring delsel cl-extra
help-mode use-package use-package-ensure use-package-delight
use-package-diminish use-package-bind-key bind-key use-package-core
finder-inf all-the-icons-autoloads tex-site company-box-autoloads
company-org-block-autoloads company-posframe-autoloads
frame-local-autoloads gist-autoloads gh-autoloads rx
magit-todos-autoloads pcre2el-autoloads poly-org-autoloads
polymode-autoloads company-autoloads pyvenv-auto-autoloads easy-mmode
shackle-autoloads slime-autoloads transient-autoloads compat-autoloads
w3m-load wgrep-autoloads info zig-mode-autoloads reformatter-autoloads
package browse-url url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util mailcap
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
password-cache json subr-x map byte-opt gv bytecomp byte-compile
url-vars cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen 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 nadvice seq simple cl-generic
indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs
theme-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 xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk x-toolkit xinput2 x multi-tty move-toolbar make-network-process
emacs)

Memory information:
((conses 16 2302621 501894) (symbols 48 60348 3)
 (strings 32 329050 68835) (string-bytes 1 9231492)
 (vectors 16 121824) (vector-slots 8 2183817 474094)
 (floats 8 1516 2584) (intervals 56 393227 5609) (buffers 992 162))


-- 
lg

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  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
  0 siblings, 2 replies; 16+ messages in thread
From: Eli Zaretskii @ 2023-10-17 11:29 UTC (permalink / raw)
  To: Evgeny Zajcev; +Cc: 66589

> 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?

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@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?

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





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-17 11:29 ` Eli Zaretskii
@ 2023-10-17 12:34   ` Gerd Möllmann
  2023-10-17 13:36   ` Evgeny Zajcev
  1 sibling, 0 replies; 16+ messages in thread
From: Gerd Möllmann @ 2023-10-17 12:34 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Evgeny Zajcev, 66589

Eli Zaretskii <eliz@gnu.org> writes:

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

Using snprintf would also be nice, if that's possible.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-17 11:29 ` Eli Zaretskii
  2023-10-17 12:34   ` Gerd Möllmann
@ 2023-10-17 13:36   ` Evgeny Zajcev
  2023-10-17 15:01     ` Eli Zaretskii
  1 sibling, 1 reply; 16+ messages in thread
From: Evgeny Zajcev @ 2023-10-17 13:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66589

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-17 13:36   ` Evgeny Zajcev
@ 2023-10-17 15:01     ` Eli Zaretskii
  2023-10-17 15:11       ` Evgeny Zajcev
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-10-17 15:01 UTC (permalink / raw)
  To: Evgeny Zajcev; +Cc: 66589

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Tue, 17 Oct 2023 16:36:17 +0300
> Cc: 66589@debbugs.gnu.org
> 
> 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

Emacs 29.0.50 is before Emacs 29.1 was released?

> (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)

This is not a valid character, I wonder how it got to this function.
Please do the below and tell what GDB produces as result:

  (gdb) frame 18
  (gdb) p/x it->c
  (gdb) p/x it->char_to_display
  (gdb) p it->method
  (gdb) pgrowx it->glyph_row

If GDB says it doesn't know abot "pgrowx", type this:

  (gdb) source /path/to/emacs/src/.gdbinit

and then repeat the pgrowx command.

Also, any chance you can describe what were you doing when the abort
happened?  In particular, what was in the buffer that was on display
in this window?





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  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
  0 siblings, 2 replies; 16+ messages in thread
From: Evgeny Zajcev @ 2023-10-17 15:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66589

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

вт, 17 окт. 2023 г. в 18:02, Eli Zaretskii <eliz@gnu.org>:

> > From: Evgeny Zajcev <lg.zevlg@gmail.com>
> > Date: Tue, 17 Oct 2023 16:36:17 +0300
> > Cc: 66589@debbugs.gnu.org
> >
> > 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
>
> Emacs 29.0.50 is before Emacs 29.1 was released?
>
> > (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)
>
> This is not a valid character, I wonder how it got to this function.
> Please do the below and tell what GDB produces as result:
>
>   (gdb) frame 18
>   (gdb) p/x it->c
>   (gdb) p/x it->char_to_display
>   (gdb) p it->method
>   (gdb) pgrowx it->glyph_row
>

(gdb) frame 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/x it->c
$2 = 0xfffc71a2
(gdb) p/x it->char_to_display
$3 = 0xa
(gdb) p it->method
$4 = GET_FROM_BUFFER
(gdb) pgrowx it->glyph_row
Undefined command: "pgrowx".  Try "help".
(gdb) source src/.gdbinit
Warning: /home/lg/dev/emacs-30/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
DISPLAY = :0
TERM = screen-256color
Breakpoint 1 at 0x55ccdf18ac6a: file emacs.c, line 446.
Breakpoint 2 at 0x55ccdf27ad60: file xterm.c, line 26945.
(gdb) pgrowx it->glyph_row
Cannot access memory at address 0x2c
(gdb)


>
> If GDB says it doesn't know abot "pgrowx", type this:
>
>   (gdb) source /path/to/emacs/src/.gdbinit
>
> and then repeat the pgrowx command.
>
> Also, any chance you can describe what were you doing when the abort
> happened?  In particular, what was in the buffer that was on display
> in this window?
>

I've been debuging process filter error, I've turned on `debug-on-error`,
waited for backtrace buffer to pop up and just after it popped up (I've
been able to see it contents) Emacs aborted.
I've restarted Emacs, did the same, backtrace buffer popped up without
abort at this time.  Also, I've been experimenting with header line at the
moment,  so my process filter has been triggering header line redrawing.
Current buffer was actually a Telegram chat opened in telega, so it might
have some strange unicode characters in it

-- 
lg

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-17 15:11       ` Evgeny Zajcev
@ 2023-10-17 15:14         ` Evgeny Zajcev
  2023-10-17 17:59         ` Eli Zaretskii
  1 sibling, 0 replies; 16+ messages in thread
From: Evgeny Zajcev @ 2023-10-17 15:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66589

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

вт, 17 окт. 2023 г. в 18:11, Evgeny Zajcev <lg.zevlg@gmail.com>:

>
> (gdb) pgrowx it->glyph_row
> Cannot access memory at address 0x2c
> (gdb)
>
>
This also might help

(gdb) p it->glyph_row
$5 = (struct glyph_row *) 0x0


-- 
lg

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  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
  1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-10-17 17:59 UTC (permalink / raw)
  To: Evgeny Zajcev; +Cc: 66589

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Tue, 17 Oct 2023 18:11:43 +0300
> Cc: 66589@debbugs.gnu.org
> 
> (gdb) frame 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/x it->c
> $2 = 0xfffc71a2
> (gdb) p/x it->char_to_display
> $3 = 0xa
> (gdb) p it->method
> $4 = GET_FROM_BUFFER
> (gdb) pgrowx it->glyph_row
> Undefined command: "pgrowx".  Try "help".
> (gdb) source src/.gdbinit
> Warning: /home/lg/dev/emacs-30/../lwlib: No such file or directory.
> SIGINT is used by the debugger.
> Are you sure you want to change it? (y or n) [answered Y; input not from
> terminal]
> DISPLAY = :0
> TERM = screen-256color
> Breakpoint 1 at 0x55ccdf18ac6a: file emacs.c, line 446.
> Breakpoint 2 at 0x55ccdf27ad60: file xterm.c, line 26945.
> (gdb) pgrowx it->glyph_row
> Cannot access memory at address 0x2c
> (gdb)

OK, thanks.  One more request:

  (gdb) frame 19
  (gdb) p it->current
  (gdb) p current_buffer->zv
  (gdb) p current_buffer->text->beg[10000]@106





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-17 17:59         ` Eli Zaretskii
@ 2023-10-17 18:11           ` Evgeny Zajcev
  2023-10-17 19:23             ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Evgeny Zajcev @ 2023-10-17 18:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66589

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

вт, 17 окт. 2023 г. в 21:00, Eli Zaretskii <eliz@gnu.org>:

> > From: Evgeny Zajcev <lg.zevlg@gmail.com>
> > Date: Tue, 17 Oct 2023 18:11:43 +0300
> > Cc: 66589@debbugs.gnu.org
> >
> > (gdb) frame 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/x it->c
> > $2 = 0xfffc71a2
> > (gdb) p/x it->char_to_display
> > $3 = 0xa
> > (gdb) p it->method
> > $4 = GET_FROM_BUFFER
> > (gdb) pgrowx it->glyph_row
> > Undefined command: "pgrowx".  Try "help".
> > (gdb) source src/.gdbinit
> > Warning: /home/lg/dev/emacs-30/../lwlib: No such file or directory.
> > SIGINT is used by the debugger.
> > Are you sure you want to change it? (y or n) [answered Y; input not from
> > terminal]
> > DISPLAY = :0
> > TERM = screen-256color
> > Breakpoint 1 at 0x55ccdf18ac6a: file emacs.c, line 446.
> > Breakpoint 2 at 0x55ccdf27ad60: file xterm.c, line 26945.
> > (gdb) pgrowx it->glyph_row
> > Cannot access memory at address 0x2c
> > (gdb)
>
> OK, thanks.  One more request:
>
>   (gdb) frame 19
>   (gdb) p it->current
>   (gdb) p current_buffer->zv
>   (gdb) p current_buffer->text->beg[10000]@106
>

(gdb) frame 19
#19 0x000055ccdf1eb141 in gui_produce_glyphs (it=0x7ffef46c5660) at
lisp.h:1179
1179      return make_lisp_symbol (&lispsym[index]);
(gdb) p it->current
$6 = {
  pos = {
    charpos = 10098,
    bytepos = 14401
  },
  overlay_string_index = -1,
  string_pos = {
    charpos = -1,
    bytepos = -1
  },
  dpvec_index = -1
}
(gdb) p current_buffer->zv
No symbol "current_buffer" in current context.
(gdb) p current_thread->m_current_buffer
$7 = (struct buffer *) 0x55ccf0885fb0
(gdb) p current_thread->m_current_buffer->zv
$8 = 10106
(gdb) p current_thread->m_current_buffer->text->beg[10000]@106
$9 = "     \n    | ⮪ Yura› Позорище 🤦‍♂ у ФСБ только на Газель Хва",
<incomplete sequence \320>
(gdb)


-- 
lg

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-17 18:11           ` Evgeny Zajcev
@ 2023-10-17 19:23             ` Eli Zaretskii
  2023-10-17 19:34               ` Evgeny Zajcev
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-10-17 19:23 UTC (permalink / raw)
  To: Evgeny Zajcev; +Cc: 66589

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Tue, 17 Oct 2023 21:11:40 +0300
> Cc: 66589@debbugs.gnu.org
> 
> (gdb) frame 19
> #19 0x000055ccdf1eb141 in gui_produce_glyphs (it=0x7ffef46c5660) at
> lisp.h:1179
> 1179      return make_lisp_symbol (&lispsym[index]);
> (gdb) p it->current
> $6 = {
>   pos = {
>     charpos = 10098,
>     bytepos = 14401
>   },
>   overlay_string_index = -1,
>   string_pos = {
>     charpos = -1,
>     bytepos = -1
>   },
>   dpvec_index = -1
> }
> (gdb) p current_buffer->zv
> No symbol "current_buffer" in current context.
> (gdb) p current_thread->m_current_buffer
> $7 = (struct buffer *) 0x55ccf0885fb0
> (gdb) p current_thread->m_current_buffer->zv
> $8 = 10106
> (gdb) p current_thread->m_current_buffer->text->beg[10000]@106
> $9 = "     \n    | ⮪ Yura› Позорище 🤦‍♂ у ФСБ только на Газель Хва",
> <incomplete sequence \320>
> (gdb)

Hmm... what about this:

  (gdb) frame 18
  (gdb) p current_thread->m_current_buffer->text->gpt_byte
  (gdb) p current_thread->m_current_buffer->zv_byte
  (gdb) p current_thread->m_current_buffer->text->beg[14350]@100





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-17 19:23             ` Eli Zaretskii
@ 2023-10-17 19:34               ` Evgeny Zajcev
  2023-10-17 19:37                 ` Evgeny Zajcev
  0 siblings, 1 reply; 16+ messages in thread
From: Evgeny Zajcev @ 2023-10-17 19:34 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66589

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

вт, 17 окт. 2023 г. в 22:23, Eli Zaretskii <eliz@gnu.org>:

> > From: Evgeny Zajcev <lg.zevlg@gmail.com>
> > Date: Tue, 17 Oct 2023 21:11:40 +0300
> > Cc: 66589@debbugs.gnu.org
> >
> > (gdb) frame 19
> > #19 0x000055ccdf1eb141 in gui_produce_glyphs (it=0x7ffef46c5660) at
> > lisp.h:1179
> > 1179      return make_lisp_symbol (&lispsym[index]);
> > (gdb) p it->current
> > $6 = {
> >   pos = {
> >     charpos = 10098,
> >     bytepos = 14401
> >   },
> >   overlay_string_index = -1,
> >   string_pos = {
> >     charpos = -1,
> >     bytepos = -1
> >   },
> >   dpvec_index = -1
> > }
> > (gdb) p current_buffer->zv
> > No symbol "current_buffer" in current context.
> > (gdb) p current_thread->m_current_buffer
> > $7 = (struct buffer *) 0x55ccf0885fb0
> > (gdb) p current_thread->m_current_buffer->zv
> > $8 = 10106
> > (gdb) p current_thread->m_current_buffer->text->beg[10000]@106
> > $9 = "     \n    | ⮪ Yura› Позорище 🤦‍♂ у ФСБ только на Газель Хва",
> > <incomplete sequence \320>
> > (gdb)
>
> Hmm... what about this:
>
>   (gdb) frame 18
>   (gdb) p current_thread->m_current_buffer->text->gpt_byte
>   (gdb) p current_thread->m_current_buffer->zv_byte
>   (gdb) p current_thread->m_current_buffer->text->beg[14350]@100
>

(gdb) frame 18
#18 produce_glyphless_glyph (it=0x7ffef46c5660,
for_no_font=for_no_font@entry=false, acronym=acronym@entry=XIL(0)) at
xdisp.c:32165
32165             sprintf (buf, "%0*X", it->c < 0x10000 ? 4 : 6, it->c +
0u);
(gdb) p current_thread->m_current_buffer->text->gpt_byte
$10 = 5287
(gdb) p current_thread->m_current_buffer->zv_byte
$11 = 14409
(gdb) p current_thread->m_current_buffer->text->beg[14350]@100
$12 = ' ' <repeats 48 times>, "11:09\n(Д) Дени", ' ' <repeats 32 times>
(gdb)

-- 
lg

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-17 19:34               ` Evgeny Zajcev
@ 2023-10-17 19:37                 ` Evgeny Zajcev
  2023-10-18 11:40                   ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Evgeny Zajcev @ 2023-10-17 19:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 66589

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

вт, 17 окт. 2023 г. в 22:34, Evgeny Zajcev <lg.zevlg@gmail.com>:

>
>
> вт, 17 окт. 2023 г. в 22:23, Eli Zaretskii <eliz@gnu.org>:
>
>> > From: Evgeny Zajcev <lg.zevlg@gmail.com>
>> > Date: Tue, 17 Oct 2023 21:11:40 +0300
>> > Cc: 66589@debbugs.gnu.org
>> >
>> > (gdb) frame 19
>> > #19 0x000055ccdf1eb141 in gui_produce_glyphs (it=0x7ffef46c5660) at
>> > lisp.h:1179
>> > 1179      return make_lisp_symbol (&lispsym[index]);
>> > (gdb) p it->current
>> > $6 = {
>> >   pos = {
>> >     charpos = 10098,
>> >     bytepos = 14401
>> >   },
>> >   overlay_string_index = -1,
>> >   string_pos = {
>> >     charpos = -1,
>> >     bytepos = -1
>> >   },
>> >   dpvec_index = -1
>> > }
>> > (gdb) p current_buffer->zv
>> > No symbol "current_buffer" in current context.
>> > (gdb) p current_thread->m_current_buffer
>> > $7 = (struct buffer *) 0x55ccf0885fb0
>> > (gdb) p current_thread->m_current_buffer->zv
>> > $8 = 10106
>> > (gdb) p current_thread->m_current_buffer->text->beg[10000]@106
>> > $9 = "     \n    | ⮪ Yura› Позорище 🤦‍♂ у ФСБ только на Газель Хва",
>> > <incomplete sequence \320>
>> > (gdb)
>>
>> Hmm... what about this:
>>
>>   (gdb) frame 18
>>   (gdb) p current_thread->m_current_buffer->text->gpt_byte
>>   (gdb) p current_thread->m_current_buffer->zv_byte
>>   (gdb) p current_thread->m_current_buffer->text->beg[14350]@100
>>
>
> (gdb) frame 18
> #18 produce_glyphless_glyph (it=0x7ffef46c5660,
> for_no_font=for_no_font@entry=false, acronym=acronym@entry=XIL(0)) at
> xdisp.c:32165
> 32165             sprintf (buf, "%0*X", it->c < 0x10000 ? 4 : 6, it->c +
> 0u);
> (gdb) p current_thread->m_current_buffer->text->gpt_byte
> $10 = 5287
> (gdb) p current_thread->m_current_buffer->zv_byte
> $11 = 14409
> (gdb) p current_thread->m_current_buffer->text->beg[14350]@100
> $12 = ' ' <repeats 48 times>, "11:09\n(Д) Дени", ' ' <repeats 32 times>
> (gdb)
>

Take into account that char between (Д) and Дени из 0xa0, not a regular
space. My gmail web interface might changed it


-- 
lg

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-17 19:37                 ` Evgeny Zajcev
@ 2023-10-18 11:40                   ` Eli Zaretskii
  2024-03-11 10:26                     ` Florian Weimer
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2023-10-18 11:40 UTC (permalink / raw)
  To: Evgeny Zajcev; +Cc: 66589

> From: Evgeny Zajcev <lg.zevlg@gmail.com>
> Date: Tue, 17 Oct 2023 22:37:08 +0300
> Cc: 66589@debbugs.gnu.org
> 
>  > (gdb) p it->current
>  > $6 = {
>  >   pos = {
>  >     charpos = 10098,
>  >     bytepos = 14401
>  >   },
>  >   overlay_string_index = -1,
>  >   string_pos = {
>  >     charpos = -1,
>  >     bytepos = -1
>  >   },
>  >   dpvec_index = -1
>  > }
>  > (gdb) p current_buffer->zv
>  > No symbol "current_buffer" in current context.
>  > (gdb) p current_thread->m_current_buffer
>  > $7 = (struct buffer *) 0x55ccf0885fb0
>  > (gdb) p current_thread->m_current_buffer->zv
>  > $8 = 10106
>  > (gdb) p current_thread->m_current_buffer->text->beg[10000]@106
>  > $9 = "     \n    | ⮪ Yura› Позорище 🤦‍♂ у ФСБ только на Газель Хва",
>  > <incomplete sequence \320>
>  > (gdb)
> 
>  Hmm... what about this:
> 
>    (gdb) frame 18
>    (gdb) p current_thread->m_current_buffer->text->gpt_byte
>    (gdb) p current_thread->m_current_buffer->zv_byte
>    (gdb) p current_thread->m_current_buffer->text->beg[14350]@100
> 
>  (gdb) frame 18
>  #18 produce_glyphless_glyph (it=0x7ffef46c5660, for_no_font=for_no_font@entry=false,
>  acronym=acronym@entry=XIL(0)) at xdisp.c:32165
>  32165             sprintf (buf, "%0*X", it->c < 0x10000 ? 4 : 6, it->c + 0u);
>  (gdb) p current_thread->m_current_buffer->text->gpt_byte
>  $10 = 5287
>  (gdb) p current_thread->m_current_buffer->zv_byte
>  $11 = 14409
>  (gdb) p current_thread->m_current_buffer->text->beg[14350]@100
>  $12 = ' ' <repeats 48 times>, "11:09\n(Д) Дени", ' ' <repeats 32 times>
>  (gdb) 
> 
> Take into account that char between (Д) and Дени из 0xa0, not a regular space. My gmail web
> interface might changed it

Very strange.  This means that both it->char_to_display and it->c are
bogus, and I have no idea how this could happen.  So it is very
important that you try to provide a reproduction recipe for this.  I
will nevertheless try to see if I can figure out how such a situation
could ever happen.





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2023-10-18 11:40                   ` Eli Zaretskii
@ 2024-03-11 10:26                     ` Florian Weimer
  2024-03-11 13:21                       ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Florian Weimer @ 2024-03-11 10:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Evgeny Zajcev, 66589

* Eli Zaretskii:

> Very strange.  This means that both it->char_to_display and it->c are
> bogus, and I have no idea how this could happen.  So it is very
> important that you try to provide a reproduction recipe for this.  I
> will nevertheless try to see if I can figure out how such a situation
> could ever happen.

For me, this (negative it->c value and subsequent fortify crash in
sprintf) happens when displaying an Arabic spam message.  This only
happens during article display.  Copying the message header and text
into a different buffer under text-mode Emacs and then opening it in
graphical Emacs does not trigger the crash for me.

Thanks,
Florian






^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2024-03-11 10:26                     ` Florian Weimer
@ 2024-03-11 13:21                       ` Eli Zaretskii
  2024-03-11 15:32                         ` Evgeny Zajcev
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2024-03-11 13:21 UTC (permalink / raw)
  To: Florian Weimer; +Cc: lg.zevlg, 66589

> From: Florian Weimer <fweimer@redhat.com>
> Cc: Evgeny Zajcev <lg.zevlg@gmail.com>,  66589@debbugs.gnu.org
> Date: Mon, 11 Mar 2024 11:26:00 +0100
> 
> * Eli Zaretskii:
> 
> > Very strange.  This means that both it->char_to_display and it->c are
> > bogus, and I have no idea how this could happen.  So it is very
> > important that you try to provide a reproduction recipe for this.  I
> > will nevertheless try to see if I can figure out how such a situation
> > could ever happen.
> 
> For me, this (negative it->c value and subsequent fortify crash in
> sprintf) happens when displaying an Arabic spam message.  This only
> happens during article display.  Copying the message header and text
> into a different buffer under text-mode Emacs and then opening it in
> graphical Emacs does not trigger the crash for me.

Thanks.  Any hope of a reproducible recipe, starting from "emacs -Q"
(and taking into consideration that I don't use Gnus and know very
little about it)?





^ permalink raw reply	[flat|nested] 16+ messages in thread

* bug#66589: 30.0.50; core dump in redisplay
  2024-03-11 13:21                       ` Eli Zaretskii
@ 2024-03-11 15:32                         ` Evgeny Zajcev
  0 siblings, 0 replies; 16+ messages in thread
From: Evgeny Zajcev @ 2024-03-11 15:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Florian Weimer, 66589

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

пн, 11 мар. 2024 г. в 16:21, Eli Zaretskii <eliz@gnu.org>:

> > From: Florian Weimer <fweimer@redhat.com>
> > Cc: Evgeny Zajcev <lg.zevlg@gmail.com>,  66589@debbugs.gnu.org
> > Date: Mon, 11 Mar 2024 11:26:00 +0100
> >
> > * Eli Zaretskii:
> >
> > > Very strange.  This means that both it->char_to_display and it->c are
> > > bogus, and I have no idea how this could happen.  So it is very
> > > important that you try to provide a reproduction recipe for this.  I
> > > will nevertheless try to see if I can figure out how such a situation
> > > could ever happen.
> >
> > For me, this (negative it->c value and subsequent fortify crash in
> > sprintf) happens when displaying an Arabic spam message.  This only
> > happens during article display.  Copying the message header and text
> > into a different buffer under text-mode Emacs and then opening it in
> > graphical Emacs does not trigger the crash for me.
>
> Thanks.  Any hope of a reproducible recipe, starting from "emacs -Q"
> (and taking into consideration that I don't use Gnus and know very
> little about it)?
>

Very hard to reproduce, since then I did not have any related crashes

-- 
lg

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2024-03-11 15:32 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

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.