Package: emacs;
Reported by: Gregor Zattler <telegraph <at> gmx.net>
Date: Thu, 9 Jan 2025 11:21:01 UTC
Severity: normal
Found in version 31.0.50
Done: Pip Cet <pipcet <at> protonmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 75459 in the body.
You can then email your comments to 75459 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
View this report as an mbox folder, status mbox, maintainer mbox
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Thu, 09 Jan 2025 11:21:02 GMT) Full text and rfc822 format available.Gregor Zattler <telegraph <at> gmx.net>:bug-gnu-emacs <at> gnu.org.
(Thu, 09 Jan 2025 11:21:02 GMT) Full text and rfc822 format available.Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
From: Gregor Zattler <telegraph <at> gmx.net> To: bug-gnu-emacs <at> gnu.org Subject: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Thu, 09 Jan 2025 12:19:26 +0100
[Message part 1 (text/plain, inline)]
Dear Emacs developers, I started Emacs with my configuration, and hit the keys to build/show the org-agenda and then clock in my default task. Then Emacs stopped in a breakpoint. I don't know what to do to get better infos besides sending you the GDB log (attachet). I'm happy to answer questions with very specific instructions, the GDB session is still open, but this is a laptop, I don't know when I will have to power it down... Otherwise till just now this build from scratch-igc worked without a hickup. Thanks, Gregor
[gdb-2025-01-09T11-58-12+01-00.txt (text/plain, inline)]
Starting program: /home/grfz/src/emacs-igc/src/emacs --debug-init -xrm --init-directory="${USER_EMACS_DIRECTORY}" --fg-daemon="${EMACS_SERVER_NAME}"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 1560416]
[Detaching after vfork from child process 1560417]
[Detaching after vfork from child process 1560418]
[Detaching after vfork from child process 1560419]
[Detaching after vfork from child process 1560423]
[Detaching after vfork from child process 1560424]
[Detaching after vfork from child process 1560478]
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Program received signal SIGSEGV, Segmentation fault.
Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
432 {
#0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
#1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h", line=line <at> entry=597) at ./src/alloc.c:8377
#2 0x00005555555b6acd in char_table_translate (obj=Python Exception <class 'gdb.error'>: value has been optimized out
, ch=32) at ./src/character.h:597
#3 0x00005555557d99a0 in re_match_2_internal (bufp=0x5555560fd6a0 <searchbufs+2912>, bufp <at> entry=0x5eb92b3c6c43c900, string1=0x0, string1 <at> entry=0x555557025101 "\377\377\377\377\377\377\377\001", size1=0, string2=0x5555570251b0 "#-*- mode: Org; indent-tabs-mode: nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP: odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO: TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"..., size2=93674, size2 <at> entry=93825020464468, pos=43986, regs=<optimized out>, stop=<optimized out>) at ./src/regex-emacs.c:4553
#4 0x00005555557de57d in re_match_2 (bufp=0x5eb92b3c6c43c900, string1=0x555557025101 "\377\377\377\377\377\377\377\001", size1=<optimized out>, string2=<optimized out>, size2=93825020464468, pos=<optimized out>, regs=<optimized out>, stop=<optimized out>) at ./src/regex-emacs.c:4056
#5 0x00005555557c9f73 in looking_at_1 (string=Python Exception <class 'gdb.error'>: value has been optimized out
, posix=<optimized out>, modify_data=<optimized out>) at ./src/search.c:323
#6 0x00007fffde1bc131 in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_38 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
#7 0x000055555581b7c7 in funcall_subr (subr=0x7fffe63117f0, numargs=4, args=<optimized out>) at ./src/eval.c:3173
#8 0x0000555555817e73 in Ffuncall (nargs=5, args=0x7fffffffb268) at ./src/eval.c:3099
#9 0x00007fffde1eea0e in F6f72672d656c656d656e742d2d70617273652d746f_org_element__parse_to_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
#10 0x000055555581b7e3 in funcall_subr (subr=0x7fffe6413978, numargs=1, args=<optimized out>) at ./src/eval.c:3171
#11 0x0000555555817e73 in Ffuncall (nargs=2, args=0x7fffffffb480) at ./src/eval.c:3099
#12 0x00007fffde1fe45e in F6f72672d656c656d656e742d2d63616368652d7665726966792d656c656d656e74_org_element__cache_verify_element_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
#13 0x000055555581b810 in funcall_subr (subr=0x7fffe95e36d8, numargs=1, args=<optimized out>) at ./src/eval.c:3167
#14 0x0000555555817e73 in Ffuncall (nargs=2, args=0x7fffffffbbd0) at ./src/eval.c:3099
#15 0x00007fffde218a4e in F6f72672d656c656d656e742d61742d706f696e74_org_element_at_point_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
#16 0x000055555581b7ff in funcall_subr (subr=0x7fffe6414738, numargs=0, args=<optimized out>) at ./src/eval.c:3169
#17 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffbd58) at ./src/eval.c:3099
#18 0x00007fffdf123c64 in F6f72672d696e2d7372632d626c6f636b2d70_org_in_src_block_p_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-30013b5a-16ff07f1.eln
#19 0x000055555581b7ff in funcall_subr (subr=0x7fffe9cec0b0, numargs=2, args=<optimized out>) at ./src/eval.c:3169
#20 0x0000555555817e73 in Ffuncall (nargs=3, args=0x7fffffffbf80) at ./src/eval.c:3099
#21 0x00007fffde296717 in F6f72672d6167656e64612d736b6970_org_agenda_skip_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
#22 0x000055555581b810 in funcall_subr (subr=0x7fffe9d601e0, numargs=0, args=<optimized out>) at ./src/eval.c:3167
#23 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffc208) at ./src/eval.c:3099
#24 0x00007fffde2bb076 in F6f72672d6167656e64612d6765742d626c6f636b73_org_agenda_get_blocks_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
#25 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffc3c0) at ./src/eval.c:3099
#26 0x00007fffde2a52cc in F6f72672d6167656e64612d6765742d6461792d656e7472696573_org_agenda_get_day_entries_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
#27 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=7, args=0x7fffffffc530) at ./src/eval.c:3099
#28 0x0000555555818220 in Fapply (nargs=<optimized out>, args=0x7fffffffc6f8) at ./src/eval.c:2771
#29 0x0000555555817e73 in Ffuncall (nargs=5, args=0x7fffffffc6f0) at ./src/eval.c:3099
#30 0x00007fffde29911e in F6f72672d6167656e64612d6c697374_org_agenda_list_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
#31 0x000055555581c583 in eval_sub (form=Python Exception <class 'gdb.error'>: value has been optimized out
) at ./src/eval.c:2614
#32 0x000055555581c6d9 in Fprogn (body=XIL(0x7fffe4e2036b)) at ./src/eval.c:443
#33 0x000055555581cadd in funcall_lambda (fun=make_fixnum(1), nargs=<optimized out>, arg_vector=<optimized out>) at ./src/eval.c:3356
#34 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=1, args=args <at> entry=0x7fffffffcab8) at ./src/eval.c:3099
#35 0x00005555558127d7 in Ffuncall_interactively (nargs=1, args=0x7fffffffcab8) at ./src/callint.c:250
#36 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffcab0) at ./src/eval.c:3099
#37 0x0000555555818478 in Fapply (nargs=nargs <at> entry=3, args=args <at> entry=0x7fffffffcab0) at ./src/eval.c:2724
#38 0x000055555581428c in Fcall_interactively (function=Python Exception <class 'gdb.error'>: value has been optimized out
, record_flag=XIL(0), keys=XIL(0x7fffe137c8c5)) at ./src/callint.c:342
#39 0x00007ffff27ee8f5 in F636f6d6d616e642d65786563757465_command_execute_0 () at /home/grfz/src/emacs-igc/src/../native-lisp/31.0.50-b708ad23/preloaded/simple-fab5b0cf-f25e9023.eln
#40 0x000055555581b7c7 in funcall_subr (subr=0x7fffe139d428, numargs=1, args=<optimized out>) at ./src/eval.c:3173
#41 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffcd60) at ./src/eval.c:3099
#42 0x000055555577666c in command_loop_1 () at ./src/keyboard.c:1556
#43 0x0000555555815d26 in internal_condition_case (bfun=bfun <at> entry=0x5555557760b0 <command_loop_1>, handlers=handlers <at> entry=XIL(0xa8), hfun=hfun <at> entry=0x55555575a510 <cmd_error>) at ./src/eval.c:1618
#44 0x0000555555758e1e in command_loop_2 (handlers=handlers <at> entry=XIL(0xa8)) at ./src/keyboard.c:1174
#45 0x0000555555815aaf in internal_catch (tag=tag <at> entry=XIL(0x15460), func=func <at> entry=0x555555758df0 <command_loop_2>, arg=Python Exception <class 'gdb.error'>: value has been optimized out
, arg <at> entry=XIL(0xa8)) at ./src/eval.c:1297
#46 0x0000555555758db9 in command_loop () at ./src/lisp.h:1240
#47 0x0000555555765535 in recursive_edit_1 () at ./src/keyboard.c:760
#48 0x00005555557658d5 in Frecursive_edit () at ./src/keyboard.c:843
#49 0x00005555555cffe5 in main (argc=5, argv=<optimized out>) at ./src/emacs.c:2646
Lisp Backtrace:
Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
432 {
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(backtrace_function) will be abandoned.
When the function is done executing, GDB will silently stop.
Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
432 {
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(backtrace_function) will be abandoned.
When the function is done executing, GDB will silently stop.
[Message part 3 (text/plain, inline)]
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2024-12-27 built on no Repository revision: c445e6ab432680c157575893a31f1fc215d596cf Repository branch: scratch/igc Windowing system distributor 'The X.Org Foundation', version 11.0.12101007 System Description: Debian GNU/Linux 12 (bookworm) Configured using: 'configure --infodir=/usr/share/info/emacs --with-json --with-file-notification=yes --with-libsystemd --with-cairo --with-x=yes --with-x-toolkit=no --without-toolkit-scroll-bars --without-gsettings --enable-check-lisp-object-type --enable-checking=yes,glyphs --with-native-compilation=yes --with-mps=yes 'CFLAGS=-ggdb3 -O3 -ffile-prefix-map=/home/grfz/src/emacs-igc=. -fstack-protector-strong -Wformat -Werror=format-security -fno-omit-frame-pointer' 'CPPFLAGS=-I/home/grfz/mps-artifacts -Wdate-time -D_FORTIFY_SOURCE=2' 'LDFLAGS=-L/home/grfz/mps-artifacts -Wl,-z,relro'' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES MPS NATIVE_COMP NOTIFY INOTIFY OLDXMENU PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF WEBP X11 XDBE XIM XINPUT2 XPM ZLIB Important settings: value of $LC_ALL: value of $LC_COLLATE: de_DE.utf8 value of $LC_CTYPE: de_DE.utf8 value of $LC_MESSAGES: POSIX value of $LC_MONETARY: de_DE.utf8 value of $LC_NUMERIC: de_DE.utf8 value of $LC_TIME: de_DE.utf8 value of $LANG: de_DE.utf8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: rainbow-delimiters-mode: t winner-mode: t which-key-mode: t mail-abbrevs-mode: t savehist-mode: t ws-butler-global-mode: t ws-butler-mode: t delete-selection-mode: t minibuffer-depth-indicate-mode: t which-function-mode: t windmove-mode: t xterm-mouse-mode: t key-chord-mode: t find-function-mode: t override-global-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t minibuffer-regexp-mode: t size-indication-mode: 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: /home/grfz/src/notmuch/emacs/notmuch-lib hides /usr/local/share/emacs/site-lisp/notmuch-lib /home/grfz/src/notmuch/emacs/coolj hides /usr/local/share/emacs/site-lisp/coolj /home/grfz/src/notmuch/emacs/notmuch-address hides /usr/local/share/emacs/site-lisp/notmuch-address /home/grfz/src/notmuch/emacs/notmuch-hello hides /usr/local/share/emacs/site-lisp/notmuch-hello /home/grfz/src/notmuch/emacs/notmuch-parser hides /usr/local/share/emacs/site-lisp/notmuch-parser /home/grfz/src/notmuch/emacs/notmuch-show hides /usr/local/share/emacs/site-lisp/notmuch-show /home/grfz/src/notmuch/emacs/notmuch-wash hides /usr/local/share/emacs/site-lisp/notmuch-wash /home/grfz/src/notmuch/emacs/notmuch-draft hides /usr/local/share/emacs/site-lisp/notmuch-draft /home/grfz/src/notmuch/emacs/notmuch-tree hides /usr/local/share/emacs/site-lisp/notmuch-tree /home/grfz/src/notmuch/emacs/notmuch-version hides /usr/local/share/emacs/site-lisp/notmuch-version /home/grfz/src/notmuch/emacs/notmuch-jump hides /usr/local/share/emacs/site-lisp/notmuch-jump /home/grfz/src/notmuch/emacs/notmuch-company hides /usr/local/share/emacs/site-lisp/notmuch-company /home/grfz/src/notmuch/emacs/notmuch hides /usr/local/share/emacs/site-lisp/notmuch /home/grfz/src/notmuch/emacs/notmuch-crypto hides /usr/local/share/emacs/site-lisp/notmuch-crypto /home/grfz/src/notmuch/emacs/notmuch-compat hides /usr/local/share/emacs/site-lisp/notmuch-compat /home/grfz/src/notmuch/emacs/notmuch-maildir-fcc hides /usr/local/share/emacs/site-lisp/notmuch-maildir-fcc /home/grfz/src/notmuch/emacs/notmuch-tag hides /usr/local/share/emacs/site-lisp/notmuch-tag /home/grfz/src/notmuch/emacs/notmuch-message hides /usr/local/share/emacs/site-lisp/notmuch-message /home/grfz/src/notmuch/emacs/notmuch-print hides /usr/local/share/emacs/site-lisp/notmuch-print /home/grfz/src/notmuch/emacs/notmuch-mua hides /usr/local/share/emacs/site-lisp/notmuch-mua /home/grfz/src/notmuch/emacs/notmuch-query hides /usr/local/share/emacs/site-lisp/notmuch-query /home/grfz/src/notmuch/emacs/notmuch-address hides /home/grfz/.config/emacs/elisp/notmuch-address /home/grfz/src/ol-notmuch/ol-notmuch hides /home/grfz/.config/emacs/elisp/ol-notmuch /home/grfz/.config/emacs/elpa-31.0/magit-4.1.3/magit-autorevert hides /home/grfz/.config/emacs/elpa-31.0/magit-section-4.1.3/magit-autorevert /home/grfz/.config/emacs/elpa-31.0/transient-0.8.1/transient hides /home/grfz/src/emacs-igc/lisp/transient /home/grfz/.config/emacs/elpa-31.0/idlwave-6.5.1/idlw-shell hides /home/grfz/src/emacs-igc/lisp/progmodes/idlw-shell /home/grfz/.config/emacs/elpa-31.0/idlwave-6.5.1/idlwave hides /home/grfz/src/emacs-igc/lisp/progmodes/idlwave /home/grfz/.config/emacs/elpa-31.0/idlwave-6.5.1/idlw-toolbar hides /home/grfz/src/emacs-igc/lisp/progmodes/idlw-toolbar /home/grfz/.config/emacs/elpa-31.0/idlwave-6.5.1/idlw-help hides /home/grfz/src/emacs-igc/lisp/progmodes/idlw-help /home/grfz/.config/emacs/elpa-31.0/idlwave-6.5.1/idlw-complete-structtag hides /home/grfz/src/emacs-igc/lisp/progmodes/idlw-complete-structtag Features: (shadow sort orgalist wcheck-mode ecomplete mail-extr tramp trampver tramp-integration files-x tramp-message tramp-compat xdg shell parse-time iso8601 tramp-loaddefs emacsbug add-log rainbow-delimiters winner which-key ol-notmuch notmuch notmuch-tree notmuch-jump notmuch-hello notmuch-show notmuch-print notmuch-crypto notmuch-mua notmuch-message notmuch-draft notmuch-maildir-fcc notmuch-address notmuch-company notmuch-parser notmuch-wash diff-mode track-changes coolj goto-addr icalendar diary-lib diary-loaddefs notmuch-tag crm notmuch-lib notmuch-version notmuch-compat hl-line mm-view mml-smime smime gnutls dig compat org-contrib org-crypt org-protocol org-clock dbus xml ob-plantuml gnus-alias advice message yank-media puny dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231 gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils finder-inf mailabbrev savehist auth-source-pass holidays holiday-loaddefs ws-butler delsel modus-operandi-theme modus-themes mb-depth which-func imenu windmove xt-mouse edmacro kmacro key-chord comp comp-cstr cl-extra help-mode warnings comp-run comp-common org ob ob-ref ob-lob ob-table ob-exp org-macro org-pcomplete pcomplete org-list org-footnote org-faces org-entities time-date noutline outline ob-emacs-lisp org-table org-loaddefs thingatpt find-func cal-menu calendar cal-loaddefs ob-tangle ol org-src sh-script rx smie treesit executable org-keys oc ob-comint comint ansi-osc ansi-color ring ob-core org-cycle org-fold org-fold-core org-compat ob-eval org-version org-macs format-spec use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key easy-mmode use-package-core async-autoloads csv-mode-autoloads debbugs-autoloads dired-git-info-autoloads hyperbole-autoloads kotl-autoloads hact set hhist idlwave-autoloads key-chord-autoloads magit-autoloads pcase magit-section-autoloads dash-autoloads minibuffer-line-autoloads org-contrib-autoloads org-autoloads orgalist-autoloads paredit-autoloads rainbow-delimiters-autoloads transient-autoloads wcheck-mode-autoloads info with-editor-autoloads ws-butler-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 cus-edit pp cus-load icons wid-edit 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 dbusbind inotify lcms2 dynamic-setting font-render-setting cairo xinput2 x multi-tty move-toolbar make-network-process native-compile mps emacs) Memory information: ((conses 24 0 0) (symbols 56 0 0) (strings 40 0 0) (string-bytes 1 0) (vectors 24 0) (vector-slots 8 0 0) (floats 24 0 0) (intervals 64 0 0) (buffers 992 0)) Ciao, -- Gregor
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Thu, 09 Jan 2025 13:05:02 GMT) Full text and rfc822 format available.Message #8 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gregor Zattler <telegraph <at> gmx.net>, Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Thu, 09 Jan 2025 15:03:49 +0200
> Date: Thu, 09 Jan 2025 12:19:26 +0100
> From: Gregor Zattler via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> 432 {
> #0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h", line=line <at> entry=597) at ./src/alloc.c:8377
> #2 0x00005555555b6acd in char_table_translate (obj=Python Exception <class 'gdb.error'>: value has been optimized out
> , ch=32) at ./src/character.h:597
> #3 0x00005555557d99a0 in re_match_2_internal (bufp=0x5555560fd6a0 <searchbufs+2912>, bufp <at> entry=0x5eb92b3c6c43c900, string1=0x0, string1 <at> entry=0x555557025101 "\377\377\377\377\377\377\377\001", size1=0, string2=0x5555570251b0 "#-*- mode: Org; indent-tabs-mode: nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP: odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO: TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"..., size2=93674, size2 <at> entry=93825020464468, pos=43986, regs=<optimized out>, stop=<optimized out>) at ./src/regex-emacs.c:4553
bufp->translate is not protected from GC?
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Thu, 09 Jan 2025 14:35:02 GMT) Full text and rfc822 format available.Message #11 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Gregor Zattler <telegraph <at> gmx.net>, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Thu, 09 Jan 2025 15:34:50 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Thu, 09 Jan 2025 12:19:26 +0100
>> From: Gregor Zattler via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>> 432 {
>> #0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>> #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h", line=line <at> entry=597) at ./src/alloc.c:8377
>> #2 0x00005555555b6acd in char_table_translate (obj=Python Exception <class 'gdb.error'>: value has been optimized out
>> , ch=32) at ./src/character.h:597
>> #3 0x00005555557d99a0 in re_match_2_internal (bufp=0x5555560fd6a0
>> <searchbufs+2912>, bufp <at> entry=0x5eb92b3c6c43c900, string1=0x0,
>> string1 <at> entry=0x555557025101 "\377\377\377\377\377\377\377\001",
>> size1=0, string2=0x5555570251b0 "#-*- mode: Org; indent-tabs-mode:
>> nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP:
>> odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO:
>> TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"..., size2=93674,
>> size2 <at> entry=93825020464468, pos=43986, regs=<optimized out>,
>> stop=<optimized out>) at ./src/regex-emacs.c:4553
>
> bufp->translate is not protected from GC?
Thanks!
I think the bufp should come from a regexp_cache entry that looking_at_1
gets from compile_pattern, and passes to re_match_2
i = re_match_2 (&cache_entry->buf, (char *) p1, s1, (char *) p2, s2,
compile_pattern chooses an entry from searchbuf_head, fills it out and
so on. I think searchbuf_head refers to entries in searchbuf, which is
an array of regexp_cache. And in syms_of_search we have
for (int i = 0; i < REGEXP_CACHE_SIZE; ++i)
{
staticpro (&searchbufs[i].regexp);
staticpro (&searchbufs[i].f_whitespace_regexp);
staticpro (&searchbufs[i].syntax_table);
}
That doesn't look sufficient, at least for igc, don't know about the old
gc. I'll see what must be added there, bufp->translate is certainly
among that, but maybe there are others.
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Thu, 09 Jan 2025 14:48:02 GMT) Full text and rfc822 format available.Message #14 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, Gregor Zattler <telegraph <at> gmx.net>, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Thu, 09 Jan 2025 14:47:43 +0000
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Date: Thu, 09 Jan 2025 12:19:26 +0100
>>> From: Gregor Zattler via "Bug reports for GNU Emacs,
>>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>>
>>> Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>>> 432 {
>>> #0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>>> #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde
>>> "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h",
>>> line=line <at> entry=597) at ./src/alloc.c:8377
>>> #2 0x00005555555b6acd in char_table_translate (obj=Python Exception <class 'gdb.error'>: value has been optimized out
>>> , ch=32) at ./src/character.h:597
>>> #3 0x00005555557d99a0 in re_match_2_internal (bufp=0x5555560fd6a0
>>> <searchbufs+2912>, bufp <at> entry=0x5eb92b3c6c43c900, string1=0x0,
>>> string1 <at> entry=0x555557025101 "\377\377\377\377\377\377\377\001",
>>> size1=0, string2=0x5555570251b0 "#-*- mode: Org; indent-tabs-mode:
>>> nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP:
>>> odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO:
>>> TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"..., size2=93674,
>>> size2 <at> entry=93825020464468, pos=43986, regs=<optimized out>,
>>> stop=<optimized out>) at ./src/regex-emacs.c:4553
>>
>> bufp->translate is not protected from GC?
>
> Thanks!
>
> I think the bufp should come from a regexp_cache entry that looking_at_1
> gets from compile_pattern, and passes to re_match_2
>
> i = re_match_2 (&cache_entry->buf, (char *) p1, s1, (char *) p2, s2,
>
> compile_pattern chooses an entry from searchbuf_head, fills it out and
> so on. I think searchbuf_head refers to entries in searchbuf, which is
> an array of regexp_cache. And in syms_of_search we have
>
> for (int i = 0; i < REGEXP_CACHE_SIZE; ++i)
> {
> staticpro (&searchbufs[i].regexp);
> staticpro (&searchbufs[i].f_whitespace_regexp);
> staticpro (&searchbufs[i].syntax_table);
> }
>
> That doesn't look sufficient, at least for igc, don't know about the old
> gc. I'll see what must be added there, bufp->translate is certainly
> among that, but maybe there are others.
Thanks! I agree with the analysis; I think it's safe for the old GC
because the table is traced through the buffer structure.
However, I don't think this is the bug we saw here: that we aborted in
backtrace_function () while trying to print a backtrace means something
very weird must have been happening to the specpdl: we verified
backtrace_p beforehand, and got the pointer from backtrace_top, so
unless the specpdl pointed to the very stack frame that was used by GDB,
what could explain this?
Gregor, can you run "print specpdl_ptr",
"print *(struct Lisp_String *)0x555557040d50", and "bt full"?
Thanks!
Pip
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Thu, 09 Jan 2025 14:53:02 GMT) Full text and rfc822 format available.Message #17 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: Gregor Zattler <telegraph <at> gmx.net>, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Thu, 09 Jan 2025 15:52:10 +0100
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Date: Thu, 09 Jan 2025 12:19:26 +0100
>>> From: Gregor Zattler via "Bug reports for GNU Emacs,
>>> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>>
>>> Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6,
>>> backtrace_limit=backtrace_limit <at> entry=2147483647) at
>>> ./src/emacs.c:432
>>> 432 {
>>> #0 terminate_due_to_signal (sig=sig <at> entry=6,
>>> backtrace_limit=backtrace_limit <at> entry=2147483647) at
>>> ./src/emacs.c:432
>>> #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde
>>> "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h",
>>> line=line <at> entry=597) at ./src/alloc.c:8377
>>> #2 0x00005555555b6acd in char_table_translate (obj=Python Exception
>>> <class 'gdb.error'>: value has been optimized out
>>> , ch=32) at ./src/character.h:597
>>> #3 0x00005555557d99a0 in re_match_2_internal (bufp=0x5555560fd6a0
>>> <searchbufs+2912>, bufp <at> entry=0x5eb92b3c6c43c900, string1=0x0,
>>> string1 <at> entry=0x555557025101 "\377\377\377\377\377\377\377\001",
>>> size1=0, string2=0x5555570251b0 "#-*- mode: Org; indent-tabs-mode:
>>> nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP:
>>> odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO:
>>> TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"..., size2=93674,
>>> size2 <at> entry=93825020464468, pos=43986, regs=<optimized out>,
>>> stop=<optimized out>) at ./src/regex-emacs.c:4553
>>
>> bufp->translate is not protected from GC?
>
> Thanks!
>
> I think the bufp should come from a regexp_cache entry that looking_at_1
> gets from compile_pattern, and passes to re_match_2
>
> i = re_match_2 (&cache_entry->buf, (char *) p1, s1, (char *) p2, s2,
>
> compile_pattern chooses an entry from searchbuf_head, fills it out and
> so on. I think searchbuf_head refers to entries in searchbuf, which is
> an array of regexp_cache. And in syms_of_search we have
>
> for (int i = 0; i < REGEXP_CACHE_SIZE; ++i)
> {
> staticpro (&searchbufs[i].regexp);
> staticpro (&searchbufs[i].f_whitespace_regexp);
> staticpro (&searchbufs[i].syntax_table);
> }
>
> That doesn't look sufficient, at least for igc, don't know about the old
> gc. I'll see what must be added there, bufp->translate is certainly
> among that, but maybe there are others.
Done, but what Pip says.
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Thu, 09 Jan 2025 15:33:01 GMT) Full text and rfc822 format available.Message #20 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gregor Zattler <telegraph <at> gmx.net> To: Pip Cet <pipcet <at> protonmail.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Thu, 09 Jan 2025 16:32:04 +0100
Hi Pip,
* Pip Cet <pipcet <at> protonmail.com> [2025-01-09; 14:47 GMT]:
> Gregor, can you run "print specpdl_ptr",
> "print *(struct Lisp_String *)0x555557040d50", and "bt full"?
(gdb) print specpdl_ptr
$4 = (union specbinding *) 0x5555567c1a50
(gdb) print *(struct Lisp_String *)0x555557040d50
$5 = {
gc_header = {
v = 144120702814523145,
gcaligned = 9 '\t'
},
u = {
s = {
size = 74027876143398912,
size_byte = 8028901113149262606,
intervals = 0xd0e000d0d646573,
data = 0x6c64616564080200 <error: Cannot access memory at address 0x6c64616564080200>
},
next = 0x106fff60d010000,
gcaligned = 0 '\000'
}
}
(gdb) bt full
#0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
#1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
#2 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
#3 0x00007fffffff986f in <function called from gdb> ()
#4 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
#5 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
#6 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
#7 0x00007fffffff992f in <function called from gdb> ()
#8 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
#9 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
#10 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
#11 0x00007fffffff99ef in <function called from gdb> ()
#12 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
#13 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
#14 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
#15 0x00007fffffff9aaf in <function called from gdb> ()
#16 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
#17 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
#18 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
#19 0x00007fffffff9b6f in <function called from gdb> ()
#20 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
#21 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h", line=line <at> entry=597) at ./src/alloc.c:8377
#22 0x00005555555b6acd in char_table_translate (obj=Python Exception <class 'gdb.error'>: value has been optimized out
, ch=32) at ./src/character.h:597
#23 0x00005555557d99a0 in re_match_2_internal (bufp=0x5555560fd6a0 <searchbufs+2912>, bufp <at> entry=0x5eb92b3c6c43c900, string1=0x0, string1 <at> entry=0x555557025101 "\377\377\377\377\377\377\377\001", size1=0, string2=0x5555570251b0 "#-*- mode: Org; indent-tabs-mode: nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP: odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO: TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"..., size2=93674, size2 <at> entry=93825020464468, pos=43986, regs=<optimized out>, stop=<optimized out>) at ./src/regex-emacs.c:4553
len = 1
corig = 32
c = 32
mcnt = <optimized out>
end1 = 0x0
end2 = 0x55555703bf9a ""
end_match_1 = 0x0
end_match_2 = 0x55555703bf9a ""
d = 0x55555702fd82 " :PROPERTIES:\n :ID: fd470568-f0eb-48a4-bf04-dada8e83de5f\n :END:\n\n - Mittwoch Goldene Zitronen\n - Treffen <2024-12-02 Mo 18:00> in Neukölln, Stuttgarter Str. 10 /\n Roseggerstr. 39"...
dend = 0x55555703bf9a ""
dfail = <optimized out>
p = 0x555557040d55 "\005"
pend = 0x555557040d8f " \377\003\376\377\377\207\376\377\377\a\001"
translate = XIL(0x7fffe0b702f5)
multibyte = false
target_multibyte = true
fail_stack = {
stack = <optimized out>,
size = <optimized out>,
avail = 3,
frame = 3
}
num_regs = 2
regstart = <optimized out>
regend = 0x7fffffff9c40
best_regs_set = false
best_regstart = 0x7fffffff9c48
best_regend = 0x7fffffff9c50
match_end = 0x0
nchars = 0
retval = -1
sa_avail = 6398840
sa_count = {
bytes = 1440
}
re_nsub = <optimized out>
#24 0x00005555557de57d in re_match_2 (bufp=0x5eb92b3c6c43c900, string1=0x555557025101 "\377\377\377\377\377\377\377\001", size1=<optimized out>, string2=<optimized out>, size2=93825020464468, pos=<optimized out>, regs=<optimized out>, stop=<optimized out>) at ./src/regex-emacs.c:4056
#25 0x00005555557c9f73 in looking_at_1 (string=Python Exception <class 'gdb.error'>: value has been optimized out
, posix=<optimized out>, modify_data=<optimized out>) at ./src/search.c:323
val = Python Exception <class 'gdb.error'>: value has been optimized out
p1 = 0x5555570251b0 "#-*- mode: Org; indent-tabs-mode: nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP: odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO: TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"...
p2 = <optimized out>
s1 = <optimized out>
s2 = <optimized out>
i = <optimized out>
modify_match_data = <optimized out>
cache_entry = 0x5555560fd680 <searchbufs+2880>
#26 0x00007fffde1bc131 in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_38 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
#27 0x000055555581b7c7 in funcall_subr (subr=0x7fffe63117f0, numargs=4, args=<optimized out>) at ./src/eval.c:3173
argbuf = {XIL(0x7fffe5607a2b), XIL(0), XIL(0x7fffffffb170), XIL(0x55555581153c), XIL(0x520), XIL(0), XIL(0), XIL(0x55555581cf4d)}
a = <optimized out>
maxargs = 4
#28 0x0000555555817e73 in Ffuncall (nargs=5, args=0x7fffffffb268) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#29 0x00007fffde1eea0e in F6f72672d656c656d656e742d2d70617273652d746f_org_element__parse_to_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
#30 0x000055555581b7e3 in funcall_subr (subr=0x7fffe6413978, numargs=1, args=<optimized out>) at ./src/eval.c:3171
argbuf = {make_fixnum(44173), XIL(0), XIL(0), XIL(0x7fffe2e46fc8), XIL(0x7fffe2e46fcb), XIL(0x55555611d1c0), XIL(0x7fffde263ea8), XIL(0x55555581cf4d)}
a = <optimized out>
maxargs = 3
#31 0x0000555555817e73 in Ffuncall (nargs=2, args=0x7fffffffb480) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#32 0x00007fffde1fe45e in F6f72672d656c656d656e742d2d63616368652d7665726966792d656c656d656e74_org_element__cache_verify_element_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
#33 0x000055555581b810 in funcall_subr (subr=0x7fffe95e36d8, numargs=1, args=<optimized out>) at ./src/eval.c:3167
argbuf = {XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0x7ffff29fcd40), XIL(0x55555611d1c0), XIL(0x55555581cf4d)}
a = <optimized out>
maxargs = 1
#34 0x0000555555817e73 in Ffuncall (nargs=2, args=0x7fffffffbbd0) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#35 0x00007fffde218a4e in F6f72672d656c656d656e742d61742d706f696e74_org_element_at_point_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
#36 0x000055555581b7ff in funcall_subr (subr=0x7fffe6414738, numargs=0, args=<optimized out>) at ./src/eval.c:3169
argbuf = {XIL(0), XIL(0), XIL(0x7fffe8c1e6b8), XIL(0x7fffe5606b85), XIL(0x7fffe8c1e6bd), XIL(0x4), XIL(0x7fffffffbcc0), XIL(0x55555581cf4d)}
a = <optimized out>
maxargs = 2
#37 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffbd58) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#38 0x00007fffdf123c64 in F6f72672d696e2d7372632d626c6f636b2d70_org_in_src_block_p_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-30013b5a-16ff07f1.eln
#39 0x000055555581b7ff in funcall_subr (subr=0x7fffe9cec0b0, numargs=2, args=<optimized out>) at ./src/eval.c:3169
argbuf = {XIL(0x360), XIL(0), XIL(0), XIL(0x5555559d4f50), XIL(0x7fffffffbec0), make_fixnum(23456248887582), XIL(0x7fffffffbed0), XIL(0x55555581cf4d)}
a = <optimized out>
maxargs = 2
#40 0x0000555555817e73 in Ffuncall (nargs=3, args=0x7fffffffbf80) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#41 0x00007fffde296717 in F6f72672d6167656e64612d736b6970_org_agenda_skip_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
#42 0x000055555581b810 in funcall_subr (subr=0x7fffe9d601e0, numargs=0, args=<optimized out>) at ./src/eval.c:3167
argbuf = {XIL(0), XIL(0), XIL(0x38), XIL(0), XIL(0x7fffffffc110), XIL(0x5555557f9350), XIL(0), XIL(0x55555581cf4d)}
a = <optimized out>
maxargs = 1
#43 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffc208) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#44 0x00007fffde2bb076 in F6f72672d6167656e64612d6765742d626c6f636b73_org_agenda_get_blocks_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
#45 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffc3c0) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#46 0x00007fffde2a52cc in F6f72672d6167656e64612d6765742d6461792d656e7472696573_org_agenda_get_day_entries_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
#47 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=7, args=0x7fffffffc530) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#48 0x0000555555818220 in Fapply (nargs=<optimized out>, args=0x7fffffffc6f8) at ./src/eval.c:2771
i = <optimized out>
funcall_nargs = 7
funcall_args = <optimized out>
spread_arg = XIL(0)
fun = Python Exception <class 'gdb.error'>: value has been optimized out
sa_avail = <optimized out>
sa_count = {
bytes = 512
}
numargs = <optimized out>
retval = Python Exception <class 'gdb.error'>: value has been optimized out
#49 0x0000555555817e73 in Ffuncall (nargs=5, args=0x7fffffffc6f0) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#50 0x00007fffde29911e in F6f72672d6167656e64612d6c697374_org_agenda_list_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
#51 0x000055555581c583 in eval_sub (form=Python Exception <class 'gdb.error'>: value has been optimized out
) at ./src/eval.c:2614
i = 4
maxargs = 4
args_left = XIL(0)
numargs = 2
original_fun = Python Exception <class 'gdb.error'>: value has been optimized out
original_args = XIL(0x7fffe4e097b3)
fun = XIL(0x7fffe6470da5)
val = Python Exception <class 'gdb.error'>: value has been optimized out
funcar = Python Exception <class 'gdb.error'>: value has been optimized out
argvals = {make_fixnum(0), XIL(0x7fffe4e097cc), XIL(0), XIL(0), XIL(0x555556150320), XIL(0x7fffffffc8a0), XIL(0x80), make_fixnum(23456249081022)}
#52 0x000055555581c6d9 in Fprogn (body=XIL(0x7fffe4e2036b)) at ./src/eval.c:443
val = XIL(0)
#53 0x000055555581cadd in funcall_lambda (fun=make_fixnum(1), nargs=<optimized out>, arg_vector=<optimized out>) at ./src/eval.c:3356
syms_left = Python Exception <class 'gdb.error'>: value has been optimized out
lexenv = Python Exception <class 'gdb.error'>: value has been optimized out
i = <optimized out>
optional = <optimized out>
rest = <optimized out>
previous_rest = <optimized out>
#54 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=1, args=args <at> entry=0x7fffffffcab8) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#55 0x00005555558127d7 in Ffuncall_interactively (nargs=1, args=0x7fffffffcab8) at ./src/callint.c:250
#56 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffcab0) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#57 0x0000555555818478 in Fapply (nargs=nargs <at> entry=3, args=args <at> entry=0x7fffffffcab0) at ./src/eval.c:2724
i = <optimized out>
funcall_nargs = <optimized out>
funcall_args = 0x0
spread_arg = XIL(0)
fun = XIL(0xae58)
sa_avail = 16384
sa_count = {
bytes = 192
}
numargs = <optimized out>
retval = Python Exception <class 'gdb.error'>: value has been optimized out
#58 0x000055555581428c in Fcall_interactively (function=Python Exception <class 'gdb.error'>: value has been optimized out
, record_flag=XIL(0), keys=XIL(0x7fffe137c8c5)) at ./src/callint.c:342
funval = Python Exception <class 'gdb.error'>: value has been optimized out
events = <optimized out>
speccount = {
bytes = 160
}
arg_from_tty = false
key_count = 2
record_then_fail = false
save_this_command = XIL(0x2aaa8ecfbc50)
save_this_original_command = XIL(0x2aaa8ecfbc50)
save_real_this_command = XIL(0x2aaa8ecfbc50)
save_last_command = XIL(0)
prefix_arg = XIL(0)
enable = XIL(0)
up_event = XIL(0)
form = Python Exception <class 'gdb.error'>: value has been optimized out
specs = XIL(0)
sa_avail = <optimized out>
sa_count = {
bytes = <optimized out>
}
string_len = <optimized out>
string = <optimized out>
string_end = <optimized out>
next_event = <optimized out>
nargs = <optimized out>
args = <optimized out>
visargs = <optimized out>
varies = <optimized out>
tem = <optimized out>
#59 0x00007ffff27ee8f5 in F636f6d6d616e642d65786563757465_command_execute_0 () at /home/grfz/src/emacs-igc/src/../native-lisp/31.0.50-b708ad23/preloaded/simple-fab5b0cf-f25e9023.eln
#60 0x000055555581b7c7 in funcall_subr (subr=0x7fffe139d428, numargs=1, args=<optimized out>) at ./src/eval.c:3173
argbuf = {XIL(0x2aaa8ecfbc50), XIL(0), XIL(0), XIL(0), XIL(0x7fffffffcc90), XIL(0x555555817e73), XIL(0x7ffff287dce0), XIL(0x55555581cf4d)}
a = <optimized out>
maxargs = 4
#61 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffcd60) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#62 0x000055555577666c in command_loop_1 () at ./src/keyboard.c:1556
cmd = Python Exception <class 'gdb.error'>: value has been optimized out
keybuf = {XIL(0x2aaa8c649708), make_fixnum(106), make_fixnum(106), make_fixnum(97), XIL(0x7fffe1e302e4), XIL(0x7fffe11e2f64), XIL(0x7fffe11e2f64), XIL(0x16c00), XIL(0x38), XIL(0x7fffe0ab759d), XIL(0x7fffe0ab759d), XIL(0x7fffffffceb0), XIL(0), XIL(0), XIL(0), make_fixnum(23456248787193), make_fixnum(0), XIL(0x5555557ff930), XIL(0), XIL(0x5555557ff588), XIL(0), XIL(0x5eb92b3c6c43c900), XIL(0), XIL(0x60), XIL(0x7fffe582e41b), XIL(0), XIL(0x5555559d4f50), XIL(0x7fffe0c6bec5), XIL(0x7fffffffced0), XIL(0x555555817b23)}
i = <optimized out>
last_pt = 1
prev_modiff = 1
prev_buffer = 0x7fffe0c6bec0
#63 0x0000555555815d26 in internal_condition_case (bfun=bfun <at> entry=0x5555557760b0 <command_loop_1>, handlers=handlers <at> entry=XIL(0xa8), hfun=hfun <at> entry=0x55555575a510 <cmd_error>) at ./src/eval.c:1618
val = XIL(0x4c)
c = 0x7fffe1e5de70
#64 0x0000555555758e1e in command_loop_2 (handlers=handlers <at> entry=XIL(0xa8)) at ./src/keyboard.c:1174
#65 0x0000555555815aaf in internal_catch (tag=tag <at> entry=XIL(0x15460), func=func <at> entry=0x555555758df0 <command_loop_2>, arg=Python Exception <class 'gdb.error'>: value has been optimized out
, arg <at> entry=XIL(0xa8)) at ./src/eval.c:1297
val = XIL(0x4c)
c = 0x7fffe1e37138
#66 0x0000555555758db9 in command_loop () at ./src/lisp.h:1240
#67 0x0000555555765535 in recursive_edit_1 () at ./src/keyboard.c:760
val = Python Exception <class 'gdb.error'>: value has been optimized out
#68 0x00005555557658d5 in Frecursive_edit () at ./src/keyboard.c:843
#69 0x00005555555cffe5 in main (argc=5, argv=<optimized out>) at ./src/emacs.c:2646
stack_bottom_variable = 0x7ffff3e92c60
old_argc = <optimized out>
no_loadup = <optimized out>
junk = 0x0
dname_arg = 0x7fffffffd7a8 "EMACS-MPS=yes"
ch_to_dir = 0x0
original_pwd = <optimized out>
dump_mode = <optimized out>
skip_args = 1
temacs = 0x0
attempt_load_pdump = <optimized out>
only_version = <optimized out>
rlim = {
rlim_cur = 10022912,
rlim_max = 18446744073709551615
}
lc_all = <optimized out>
sockfd = <optimized out>
module_assertions = <optimized out>
Lisp Backtrace:
eval.c:118: Emacs fatal error: assertion failed: pdl->kind == SPECPDL_BACKTRACE
Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
432 {
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(backtrace_function) will be abandoned.
When the function is done executing, GDB will silently stop.
HTH, Gregor
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Thu, 09 Jan 2025 16:15:02 GMT) Full text and rfc822 format available.Message #23 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Gregor Zattler <telegraph <at> gmx.net> Cc: Pip Cet <pipcet <at> protonmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Thu, 09 Jan 2025 17:14:19 +0100
Gregor Zattler <telegraph <at> gmx.net> writes:
> Hi Pip,
> * Pip Cet <pipcet <at> protonmail.com> [2025-01-09; 14:47 GMT]:
>> Gregor, can you run "print specpdl_ptr",
>> "print *(struct Lisp_String *)0x555557040d50", and "bt full"?
>
> (gdb) print specpdl_ptr
> $4 = (union specbinding *) 0x5555567c1a50
>
> (gdb) print *(struct Lisp_String *)0x555557040d50
> $5 = {
> gc_header = {
> v = 144120702814523145,
> gcaligned = 9 '\t'
> },
> u = {
> s = {
> size = 74027876143398912,
> size_byte = 8028901113149262606,
> intervals = 0xd0e000d0d646573,
> data = 0x6c64616564080200 <error: Cannot access memory at address 0x6c64616564080200>
> },
> next = 0x106fff60d010000,
> gcaligned = 0 '\000'
> }
> }
>
> (gdb) bt full
> #0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
> #2 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
> #3 0x00007fffffff986f in <function called from gdb> ()
> #4 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> #5 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
> #6 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
> #7 0x00007fffffff992f in <function called from gdb> ()
> #8 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> #9 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
> #10 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
> #11 0x00007fffffff99ef in <function called from gdb> ()
> #12 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> #13 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
> #14 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
> #15 0x00007fffffff9aaf in <function called from gdb> ()
> #16 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> #17 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
> #18 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
> #19 0x00007fffffff9b6f in <function called from gdb> ()
> #20 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> #21 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h", line=line <at> entry=597) at ./src/alloc.c:8377
> #22 0x00005555555b6acd in char_table_translate (obj=Python Exception <class 'gdb.error'>: value has been optimized out
> , ch=32) at ./src/character.h:597
> #23 0x00005555557d99a0 in re_match_2_internal (bufp=0x5555560fd6a0 <searchbufs+2912>, bufp <at> entry=0x5eb92b3c6c43c900, string1=0x0, string1 <at> entry=0x555557025101 "\377\377\377\377\377\377\377\001", size1=0, string2=0x5555570251b0 "#-*- mode: Org; indent-tabs-mode: nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP: odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO: TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"..., size2=93674, size2 <at> entry=93825020464468, pos=43986, regs=<optimized out>, stop=<optimized out>) at ./src/regex-emacs.c:4553
> len = 1
> corig = 32
> c = 32
> mcnt = <optimized out>
> end1 = 0x0
> end2 = 0x55555703bf9a ""
> end_match_1 = 0x0
> end_match_2 = 0x55555703bf9a ""
> d = 0x55555702fd82 " :PROPERTIES:\n :ID: fd470568-f0eb-48a4-bf04-dada8e83de5f\n :END:\n\n - Mittwoch Goldene Zitronen\n - Treffen <2024-12-02 Mo 18:00> in Neukölln, Stuttgarter Str. 10 /\n Roseggerstr. 39"...
> dend = 0x55555703bf9a ""
> dfail = <optimized out>
> p = 0x555557040d55 "\005"
> pend = 0x555557040d8f " \377\003\376\377\377\207\376\377\377\a\001"
> translate = XIL(0x7fffe0b702f5)
> multibyte = false
> target_multibyte = true
> fail_stack = {
> stack = <optimized out>,
> size = <optimized out>,
> avail = 3,
> frame = 3
> }
> num_regs = 2
> regstart = <optimized out>
> regend = 0x7fffffff9c40
> best_regs_set = false
> best_regstart = 0x7fffffff9c48
> best_regend = 0x7fffffff9c50
> match_end = 0x0
> nchars = 0
> retval = -1
> sa_avail = 6398840
> sa_count = {
> bytes = 1440
> }
> re_nsub = <optimized out>
> #24 0x00005555557de57d in re_match_2 (bufp=0x5eb92b3c6c43c900, string1=0x555557025101 "\377\377\377\377\377\377\377\001", size1=<optimized out>, string2=<optimized out>, size2=93825020464468, pos=<optimized out>, regs=<optimized out>, stop=<optimized out>) at ./src/regex-emacs.c:4056
> #25 0x00005555557c9f73 in looking_at_1 (string=Python Exception <class 'gdb.error'>: value has been optimized out
> , posix=<optimized out>, modify_data=<optimized out>) at ./src/search.c:323
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> p1 = 0x5555570251b0 "#-*- mode: Org; indent-tabs-mode: nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP: odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO: TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"...
> p2 = <optimized out>
> s1 = <optimized out>
> s2 = <optimized out>
> i = <optimized out>
> modify_match_data = <optimized out>
> cache_entry = 0x5555560fd680 <searchbufs+2880>
> #26 0x00007fffde1bc131 in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_38 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
> #27 0x000055555581b7c7 in funcall_subr (subr=0x7fffe63117f0, numargs=4, args=<optimized out>) at ./src/eval.c:3173
> argbuf = {XIL(0x7fffe5607a2b), XIL(0), XIL(0x7fffffffb170), XIL(0x55555581153c), XIL(0x520), XIL(0), XIL(0), XIL(0x55555581cf4d)}
> a = <optimized out>
> maxargs = 4
> #28 0x0000555555817e73 in Ffuncall (nargs=5, args=0x7fffffffb268) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #29 0x00007fffde1eea0e in F6f72672d656c656d656e742d2d70617273652d746f_org_element__parse_to_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
> #30 0x000055555581b7e3 in funcall_subr (subr=0x7fffe6413978, numargs=1, args=<optimized out>) at ./src/eval.c:3171
> argbuf = {make_fixnum(44173), XIL(0), XIL(0), XIL(0x7fffe2e46fc8), XIL(0x7fffe2e46fcb), XIL(0x55555611d1c0), XIL(0x7fffde263ea8), XIL(0x55555581cf4d)}
> a = <optimized out>
> maxargs = 3
> #31 0x0000555555817e73 in Ffuncall (nargs=2, args=0x7fffffffb480) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #32 0x00007fffde1fe45e in F6f72672d656c656d656e742d2d63616368652d7665726966792d656c656d656e74_org_element__cache_verify_element_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
> #33 0x000055555581b810 in funcall_subr (subr=0x7fffe95e36d8, numargs=1, args=<optimized out>) at ./src/eval.c:3167
> argbuf = {XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0x7ffff29fcd40), XIL(0x55555611d1c0), XIL(0x55555581cf4d)}
> a = <optimized out>
> maxargs = 1
> #34 0x0000555555817e73 in Ffuncall (nargs=2, args=0x7fffffffbbd0) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #35 0x00007fffde218a4e in F6f72672d656c656d656e742d61742d706f696e74_org_element_at_point_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
> #36 0x000055555581b7ff in funcall_subr (subr=0x7fffe6414738, numargs=0, args=<optimized out>) at ./src/eval.c:3169
> argbuf = {XIL(0), XIL(0), XIL(0x7fffe8c1e6b8), XIL(0x7fffe5606b85), XIL(0x7fffe8c1e6bd), XIL(0x4), XIL(0x7fffffffbcc0), XIL(0x55555581cf4d)}
> a = <optimized out>
> maxargs = 2
> #37 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffbd58) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #38 0x00007fffdf123c64 in F6f72672d696e2d7372632d626c6f636b2d70_org_in_src_block_p_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-30013b5a-16ff07f1.eln
> #39 0x000055555581b7ff in funcall_subr (subr=0x7fffe9cec0b0, numargs=2, args=<optimized out>) at ./src/eval.c:3169
> argbuf = {XIL(0x360), XIL(0), XIL(0), XIL(0x5555559d4f50), XIL(0x7fffffffbec0), make_fixnum(23456248887582), XIL(0x7fffffffbed0), XIL(0x55555581cf4d)}
> a = <optimized out>
> maxargs = 2
> #40 0x0000555555817e73 in Ffuncall (nargs=3, args=0x7fffffffbf80) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #41 0x00007fffde296717 in F6f72672d6167656e64612d736b6970_org_agenda_skip_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
> #42 0x000055555581b810 in funcall_subr (subr=0x7fffe9d601e0, numargs=0, args=<optimized out>) at ./src/eval.c:3167
> argbuf = {XIL(0), XIL(0), XIL(0x38), XIL(0), XIL(0x7fffffffc110), XIL(0x5555557f9350), XIL(0), XIL(0x55555581cf4d)}
> a = <optimized out>
> maxargs = 1
> #43 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffc208) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #44 0x00007fffde2bb076 in F6f72672d6167656e64612d6765742d626c6f636b73_org_agenda_get_blocks_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
> #45 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffc3c0) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #46 0x00007fffde2a52cc in F6f72672d6167656e64612d6765742d6461792d656e7472696573_org_agenda_get_day_entries_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
> #47 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=7, args=0x7fffffffc530) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #48 0x0000555555818220 in Fapply (nargs=<optimized out>, args=0x7fffffffc6f8) at ./src/eval.c:2771
> i = <optimized out>
> funcall_nargs = 7
> funcall_args = <optimized out>
> spread_arg = XIL(0)
> fun = Python Exception <class 'gdb.error'>: value has been optimized out
>
> sa_avail = <optimized out>
> sa_count = {
> bytes = 512
> }
> numargs = <optimized out>
> retval = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #49 0x0000555555817e73 in Ffuncall (nargs=5, args=0x7fffffffc6f0) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #50 0x00007fffde29911e in F6f72672d6167656e64612d6c697374_org_agenda_list_0 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
> #51 0x000055555581c583 in eval_sub (form=Python Exception <class 'gdb.error'>: value has been optimized out
> ) at ./src/eval.c:2614
> i = 4
> maxargs = 4
> args_left = XIL(0)
> numargs = 2
> original_fun = Python Exception <class 'gdb.error'>: value has been optimized out
>
> original_args = XIL(0x7fffe4e097b3)
> fun = XIL(0x7fffe6470da5)
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> funcar = Python Exception <class 'gdb.error'>: value has been optimized out
>
> argvals = {make_fixnum(0), XIL(0x7fffe4e097cc), XIL(0), XIL(0), XIL(0x555556150320), XIL(0x7fffffffc8a0), XIL(0x80), make_fixnum(23456249081022)}
> #52 0x000055555581c6d9 in Fprogn (body=XIL(0x7fffe4e2036b)) at ./src/eval.c:443
> val = XIL(0)
> #53 0x000055555581cadd in funcall_lambda (fun=make_fixnum(1), nargs=<optimized out>, arg_vector=<optimized out>) at ./src/eval.c:3356
> syms_left = Python Exception <class 'gdb.error'>: value has been optimized out
>
> lexenv = Python Exception <class 'gdb.error'>: value has been optimized out
>
> i = <optimized out>
> optional = <optimized out>
> rest = <optimized out>
> previous_rest = <optimized out>
> #54 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=1, args=args <at> entry=0x7fffffffcab8) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #55 0x00005555558127d7 in Ffuncall_interactively (nargs=1, args=0x7fffffffcab8) at ./src/callint.c:250
> #56 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffcab0) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #57 0x0000555555818478 in Fapply (nargs=nargs <at> entry=3, args=args <at> entry=0x7fffffffcab0) at ./src/eval.c:2724
> i = <optimized out>
> funcall_nargs = <optimized out>
> funcall_args = 0x0
> spread_arg = XIL(0)
> fun = XIL(0xae58)
> sa_avail = 16384
> sa_count = {
> bytes = 192
> }
> numargs = <optimized out>
> retval = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #58 0x000055555581428c in Fcall_interactively (function=Python Exception <class 'gdb.error'>: value has been optimized out
> , record_flag=XIL(0), keys=XIL(0x7fffe137c8c5)) at ./src/callint.c:342
> funval = Python Exception <class 'gdb.error'>: value has been optimized out
>
> events = <optimized out>
> speccount = {
> bytes = 160
> }
> arg_from_tty = false
> key_count = 2
> record_then_fail = false
> save_this_command = XIL(0x2aaa8ecfbc50)
> save_this_original_command = XIL(0x2aaa8ecfbc50)
> save_real_this_command = XIL(0x2aaa8ecfbc50)
> save_last_command = XIL(0)
> prefix_arg = XIL(0)
> enable = XIL(0)
> up_event = XIL(0)
> form = Python Exception <class 'gdb.error'>: value has been optimized out
>
> specs = XIL(0)
> sa_avail = <optimized out>
> sa_count = {
> bytes = <optimized out>
> }
> string_len = <optimized out>
> string = <optimized out>
> string_end = <optimized out>
> next_event = <optimized out>
> nargs = <optimized out>
> args = <optimized out>
> visargs = <optimized out>
> varies = <optimized out>
> tem = <optimized out>
> #59 0x00007ffff27ee8f5 in F636f6d6d616e642d65786563757465_command_execute_0 () at /home/grfz/src/emacs-igc/src/../native-lisp/31.0.50-b708ad23/preloaded/simple-fab5b0cf-f25e9023.eln
> #60 0x000055555581b7c7 in funcall_subr (subr=0x7fffe139d428, numargs=1, args=<optimized out>) at ./src/eval.c:3173
> argbuf = {XIL(0x2aaa8ecfbc50), XIL(0), XIL(0), XIL(0), XIL(0x7fffffffcc90), XIL(0x555555817e73), XIL(0x7ffff287dce0), XIL(0x55555581cf4d)}
> a = <optimized out>
> maxargs = 4
> #61 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffcd60) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #62 0x000055555577666c in command_loop_1 () at ./src/keyboard.c:1556
> cmd = Python Exception <class 'gdb.error'>: value has been optimized out
>
> keybuf = {XIL(0x2aaa8c649708), make_fixnum(106), make_fixnum(106), make_fixnum(97), XIL(0x7fffe1e302e4), XIL(0x7fffe11e2f64), XIL(0x7fffe11e2f64), XIL(0x16c00), XIL(0x38), XIL(0x7fffe0ab759d), XIL(0x7fffe0ab759d), XIL(0x7fffffffceb0), XIL(0), XIL(0), XIL(0), make_fixnum(23456248787193), make_fixnum(0), XIL(0x5555557ff930), XIL(0), XIL(0x5555557ff588), XIL(0), XIL(0x5eb92b3c6c43c900), XIL(0), XIL(0x60), XIL(0x7fffe582e41b), XIL(0), XIL(0x5555559d4f50), XIL(0x7fffe0c6bec5), XIL(0x7fffffffced0), XIL(0x555555817b23)}
> i = <optimized out>
> last_pt = 1
> prev_modiff = 1
> prev_buffer = 0x7fffe0c6bec0
> #63 0x0000555555815d26 in internal_condition_case (bfun=bfun <at> entry=0x5555557760b0 <command_loop_1>, handlers=handlers <at> entry=XIL(0xa8), hfun=hfun <at> entry=0x55555575a510 <cmd_error>) at ./src/eval.c:1618
> val = XIL(0x4c)
> c = 0x7fffe1e5de70
> #64 0x0000555555758e1e in command_loop_2 (handlers=handlers <at> entry=XIL(0xa8)) at ./src/keyboard.c:1174
> #65 0x0000555555815aaf in internal_catch (tag=tag <at> entry=XIL(0x15460), func=func <at> entry=0x555555758df0 <command_loop_2>, arg=Python Exception <class 'gdb.error'>: value has been optimized out
> , arg <at> entry=XIL(0xa8)) at ./src/eval.c:1297
> val = XIL(0x4c)
> c = 0x7fffe1e37138
> #66 0x0000555555758db9 in command_loop () at ./src/lisp.h:1240
> #67 0x0000555555765535 in recursive_edit_1 () at ./src/keyboard.c:760
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #68 0x00005555557658d5 in Frecursive_edit () at ./src/keyboard.c:843
> #69 0x00005555555cffe5 in main (argc=5, argv=<optimized out>) at ./src/emacs.c:2646
> stack_bottom_variable = 0x7ffff3e92c60
> old_argc = <optimized out>
> no_loadup = <optimized out>
> junk = 0x0
> dname_arg = 0x7fffffffd7a8 "EMACS-MPS=yes"
> ch_to_dir = 0x0
> original_pwd = <optimized out>
> dump_mode = <optimized out>
> skip_args = 1
> temacs = 0x0
> attempt_load_pdump = <optimized out>
> only_version = <optimized out>
> rlim = {
> rlim_cur = 10022912,
> rlim_max = 18446744073709551615
> }
> lc_all = <optimized out>
> sockfd = <optimized out>
> module_assertions = <optimized out>
>
> Lisp Backtrace:
>
> eval.c:118: Emacs fatal error: assertion failed: pdl->kind == SPECPDL_BACKTRACE
>
> Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> 432 {
> The program being debugged stopped while in a function called from GDB.
> Evaluation of the expression containing the function
> (backtrace_function) will be abandoned.
> When the function is done executing, GDB will silently stop.
>
>
>
> HTH, Gregor
I'm wondering what should have been the specpdl entry. This one?
#26 0x00007fffde1bc131 in F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_38 () at /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
The rest, I think, is die -> backtrace -> assert -> die -> backtrace -> assert ... until it
stops. Weird.
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Thu, 09 Jan 2025 19:29:02 GMT) Full text and rfc822 format available.Message #26 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Gregor Zattler <telegraph <at> gmx.net>, Eli Zaretskii <eliz <at> gnu.org>, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Thu, 09 Jan 2025 19:27:55 +0000
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Gregor Zattler <telegraph <at> gmx.net> writes:
>
>> Hi Pip,
>> * Pip Cet <pipcet <at> protonmail.com> [2025-01-09; 14:47 GMT]:
>>> Gregor, can you run "print specpdl_ptr",
>>> "print *(struct Lisp_String *)0x555557040d50", and "bt full"?
>>
>> (gdb) print specpdl_ptr
>> $4 = (union specbinding *) 0x5555567c1a50
>>
>> (gdb) print *(struct Lisp_String *)0x555557040d50
It's not a string, but the data you printed is... weird. Usually you
can recognize pointers, or it's all ASCII, but this seems to be very
short ASCII strings betwen data in a totally different format.
>> $5 = {
>> gc_header = {
>> v = 144120702814523145,
>> gcaligned = 9 '\t'
>> },
>> u = {
>> s = {
>> size = 74027876143398912,
>> size_byte = 8028901113149262606,
"clo"
>> intervals = 0xd0e000d0d646573,
"sed"
>> data = 0x6c64616564080200 <error: Cannot access memory at address 0x6c64616564080200>
"deadl", which appears at the beginning of an Emacs string ("deadline") only in
org-agenda.el. The string is unlikely to start earlier because the next
byte would be 0x08, an ASCII backspace. Unlikely.
More likely it's an unaligned string. I think Emacs string data is
always aligned, except for pure strings. But on scratch/igc, even pure
strings are aligned to an 8-byte boundary!
"closed" also appears in org-agenda.el, but this string isn't
NUL-terminated: it's a Pascal-style string, with a length byte (0x06)
followed by 6 ASCII characters. That would match the 8-byte "deadline"
literal.
Possibly a (basic) compression format, probably lz4 or zlib. I'm
guessing this is a git object, which is stored in zlib format, and that
appears to use length-prefixed string literals like these.
What is it doing in your Emacs data?
>> },
>> next = 0x106fff60d010000,
>> gcaligned = 0 '\000'
>> }
>> }
>>
>> (gdb) bt full
>> #0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>> #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540
> "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
>> #2 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
>> #3 0x00007fffffff986f in <function called from gdb> ()
>> #4 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>> #5 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540
> "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
>> #6 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
>> #7 0x00007fffffff992f in <function called from gdb> ()
>> #8 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>> #9 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540
> "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
>> #10 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
>> #11 0x00007fffffff99ef in <function called from gdb> ()
>> #12 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>> #13 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540
> "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
>> #14 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
>> #15 0x00007fffffff9aaf in <function called from gdb> ()
>> #16 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>> #17 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540
> "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
>> #18 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
>> #19 0x00007fffffff9b6f in <function called from gdb> ()
>> #20 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>> #21 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde
> "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h",
> line=line <at> entry=597) at ./src/alloc.c:8377
>> #22 0x00005555555b6acd in char_table_translate (obj=Python Exception <class 'gdb.error'>: value has been optimized out
>> , ch=32) at ./src/character.h:597
>> #23 0x00005555557d99a0 in re_match_2_internal (bufp=0x5555560fd6a0
> <searchbufs+2912>, bufp <at> entry=0x5eb92b3c6c43c900, string1=0x0,
> string1 <at> entry=0x555557025101 "\377\377\377\377\377\377\377\001",
> size1=0, string2=0x5555570251b0 "#-*- mode: Org; indent-tabs-mode:
> nil; coding: utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP:
> odd\n;#+STARTUP: overview\n#+STARTUP: showeverything\n#+SEQ_TODO:
> TODO(t) INPROGRESS(i@/@) WAITING(w@/@) VER"..., size2=93674,
> size2 <at> entry=93825020464468, pos=43986, regs=<optimized out>,
> stop=<optimized out>) at ./src/regex-emacs.c:4553
>> len = 1
>> corig = 32
>> c = 32
>> mcnt = <optimized out>
>> end1 = 0x0
>> end2 = 0x55555703bf9a ""
>> end_match_1 = 0x0
>> end_match_2 = 0x55555703bf9a ""
>> d = 0x55555702fd82 " :PROPERTIES:\n :ID:
> fd470568-f0eb-48a4-bf04-dada8e83de5f\n :END:\n\n - Mittwoch Goldene
> Zitronen\n - Treffen <2024-12-02 Mo 18:00> in Neukölln, Stuttgarter
> Str. 10 /\n Roseggerstr. 39"...
>> dend = 0x55555703bf9a ""
>> dfail = <optimized out>
>> p = 0x555557040d55 "\005"
That's a pointer into the zlib (?) data, but at a different offset from
the last one, which was 0x555557040d54
>> pend = 0x555557040d8f " \377\003\376\377\377\207\376\377\377\a\001"
>> translate = XIL(0x7fffe0b702f5)
>> multibyte = false
>> target_multibyte = true
>> fail_stack = {
>> stack = <optimized out>,
>> size = <optimized out>,
>> avail = 3,
>> frame = 3
>> }
>> num_regs = 2
>> regstart = <optimized out>
>> regend = 0x7fffffff9c40
>> best_regs_set = false
>> best_regstart = 0x7fffffff9c48
>> best_regend = 0x7fffffff9c50
>> match_end = 0x0
>> nchars = 0
>> retval = -1
>> sa_avail = 6398840
sa_avail should never exceed 16K, but maybe it's uninitialized at this
point.
>> sa_count = {
>> bytes = 1440
>> }
>> re_nsub = <optimized out>
>> #24 0x00005555557de57d in re_match_2 (bufp=0x5eb92b3c6c43c900,
> string1=0x555557025101 "\377\377\377\377\377\377\377\001",
> size1=<optimized out>, string2=<optimized out>, size2=93825020464468,
> pos=<optimized out>, regs=<optimized out>, stop=<optimized out>) at
> ./src/regex-emacs.c:4056
>> #25 0x00005555557c9f73 in looking_at_1 (string=Python Exception <class 'gdb.error'>: value has been optimized out
>> , posix=<optimized out>, modify_data=<optimized out>) at ./src/search.c:323
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> p1 = 0x5555570251b0 "#-*- mode: Org; indent-tabs-mode: nil; coding:
> utf-8-unix -*-\n#+STARTUP: hidestars\n#+STARTUP: odd\n;#+STARTUP:
> overview\n#+STARTUP: showeverything\n#+SEQ_TODO: TODO(t)
> INPROGRESS(i@/@) WAITING(w@/@) VER"...
>> p2 = <optimized out>
>> s1 = <optimized out>
>> s2 = <optimized out>
>> i = <optimized out>
>> modify_match_data = <optimized out>
>> cache_entry = 0x5555560fd680 <searchbufs+2880>
>> #26 0x00007fffde1bc131 in
> F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_38 () at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
>> #27 0x000055555581b7c7 in funcall_subr (subr=0x7fffe63117f0, numargs=4, args=<optimized out>) at ./src/eval.c:3173
>> argbuf = {XIL(0x7fffe5607a2b), XIL(0), XIL(0x7fffffffb170), XIL(0x55555581153c), XIL(0x520), XIL(0), XIL(0), XIL(0x55555581cf4d)}
>> a = <optimized out>
>> maxargs = 4
>> #28 0x0000555555817e73 in Ffuncall (nargs=5, args=0x7fffffffb268) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #29 0x00007fffde1eea0e in
> F6f72672d656c656d656e742d2d70617273652d746f_org_element__parse_to_0 ()
> at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
>> #30 0x000055555581b7e3 in funcall_subr (subr=0x7fffe6413978, numargs=1, args=<optimized out>) at ./src/eval.c:3171
>> argbuf = {make_fixnum(44173), XIL(0), XIL(0), XIL(0x7fffe2e46fc8),
> XIL(0x7fffe2e46fcb), XIL(0x55555611d1c0), XIL(0x7fffde263ea8),
> XIL(0x55555581cf4d)}
>> a = <optimized out>
>> maxargs = 3
>> #31 0x0000555555817e73 in Ffuncall (nargs=2, args=0x7fffffffb480) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #32 0x00007fffde1fe45e in
> F6f72672d656c656d656e742d2d63616368652d7665726966792d656c656d656e74_org_element__cache_verify_element_0
> () at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
>> #33 0x000055555581b810 in funcall_subr (subr=0x7fffe95e36d8, numargs=1, args=<optimized out>) at ./src/eval.c:3167
>> argbuf = {XIL(0), XIL(0), XIL(0), XIL(0), XIL(0), XIL(0x7ffff29fcd40), XIL(0x55555611d1c0), XIL(0x55555581cf4d)}
>> a = <optimized out>
>> maxargs = 1
>> #34 0x0000555555817e73 in Ffuncall (nargs=2, args=0x7fffffffbbd0) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #35 0x00007fffde218a4e in
> F6f72672d656c656d656e742d61742d706f696e74_org_element_at_point_0 () at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
>> #36 0x000055555581b7ff in funcall_subr (subr=0x7fffe6414738, numargs=0, args=<optimized out>) at ./src/eval.c:3169
>> argbuf = {XIL(0), XIL(0), XIL(0x7fffe8c1e6b8), XIL(0x7fffe5606b85), XIL(0x7fffe8c1e6bd), XIL(0x4), XIL(0x7fffffffbcc0), XIL(0x55555581cf4d)}
>> a = <optimized out>
>> maxargs = 2
>> #37 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffbd58) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #38 0x00007fffdf123c64 in
> F6f72672d696e2d7372632d626c6f636b2d70_org_in_src_block_p_0 () at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-30013b5a-16ff07f1.eln
>> #39 0x000055555581b7ff in funcall_subr (subr=0x7fffe9cec0b0, numargs=2, args=<optimized out>) at ./src/eval.c:3169
>> argbuf = {XIL(0x360), XIL(0), XIL(0), XIL(0x5555559d4f50),
> XIL(0x7fffffffbec0), make_fixnum(23456248887582), XIL(0x7fffffffbed0),
> XIL(0x55555581cf4d)}
>> a = <optimized out>
>> maxargs = 2
>> #40 0x0000555555817e73 in Ffuncall (nargs=3, args=0x7fffffffbf80) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #41 0x00007fffde296717 in
> F6f72672d6167656e64612d736b6970_org_agenda_skip_0 () at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
>> #42 0x000055555581b810 in funcall_subr (subr=0x7fffe9d601e0, numargs=0, args=<optimized out>) at ./src/eval.c:3167
>> argbuf = {XIL(0), XIL(0), XIL(0x38), XIL(0), XIL(0x7fffffffc110), XIL(0x5555557f9350), XIL(0), XIL(0x55555581cf4d)}
>> a = <optimized out>
>> maxargs = 1
>> #43 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffc208) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #44 0x00007fffde2bb076 in
> F6f72672d6167656e64612d6765742d626c6f636b73_org_agenda_get_blocks_0 ()
> at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
>> #45 0x0000555555817e73 in Ffuncall (nargs=1, args=0x7fffffffc3c0) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #46 0x00007fffde2a52cc in
> F6f72672d6167656e64612d6765742d6461792d656e7472696573_org_agenda_get_day_entries_0
> () at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
>> #47 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=7, args=0x7fffffffc530) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #48 0x0000555555818220 in Fapply (nargs=<optimized out>, args=0x7fffffffc6f8) at ./src/eval.c:2771
>> i = <optimized out>
>> funcall_nargs = 7
>> funcall_args = <optimized out>
>> spread_arg = XIL(0)
>> fun = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> sa_avail = <optimized out>
>> sa_count = {
>> bytes = 512
>> }
>> numargs = <optimized out>
>> retval = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #49 0x0000555555817e73 in Ffuncall (nargs=5, args=0x7fffffffc6f0) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #50 0x00007fffde29911e in
> F6f72672d6167656e64612d6c697374_org_agenda_list_0 () at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-agenda-c62ea9fb-0f9a50be.eln
>> #51 0x000055555581c583 in eval_sub (form=Python Exception <class 'gdb.error'>: value has been optimized out
>> ) at ./src/eval.c:2614
>> i = 4
>> maxargs = 4
>> args_left = XIL(0)
>> numargs = 2
>> original_fun = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> original_args = XIL(0x7fffe4e097b3)
>> fun = XIL(0x7fffe6470da5)
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> funcar = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> argvals = {make_fixnum(0), XIL(0x7fffe4e097cc), XIL(0), XIL(0), XIL(0x555556150320), XIL(0x7fffffffc8a0), XIL(0x80), make_fixnum(23456249081022)}
>> #52 0x000055555581c6d9 in Fprogn (body=XIL(0x7fffe4e2036b)) at ./src/eval.c:443
>> val = XIL(0)
>> #53 0x000055555581cadd in funcall_lambda (fun=make_fixnum(1), nargs=<optimized out>, arg_vector=<optimized out>) at ./src/eval.c:3356
>> syms_left = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> lexenv = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> i = <optimized out>
>> optional = <optimized out>
>> rest = <optimized out>
>> previous_rest = <optimized out>
>> #54 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=1, args=args <at> entry=0x7fffffffcab8) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #55 0x00005555558127d7 in Ffuncall_interactively (nargs=1, args=0x7fffffffcab8) at ./src/callint.c:250
>> #56 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffcab0) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #57 0x0000555555818478 in Fapply (nargs=nargs <at> entry=3, args=args <at> entry=0x7fffffffcab0) at ./src/eval.c:2724
>> i = <optimized out>
>> funcall_nargs = <optimized out>
>> funcall_args = 0x0
>> spread_arg = XIL(0)
>> fun = XIL(0xae58)
>> sa_avail = 16384
>> sa_count = {
>> bytes = 192
>> }
>> numargs = <optimized out>
>> retval = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #58 0x000055555581428c in Fcall_interactively (function=Python Exception <class 'gdb.error'>: value has been optimized out
>> , record_flag=XIL(0), keys=XIL(0x7fffe137c8c5)) at ./src/callint.c:342
>> funval = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> events = <optimized out>
>> speccount = {
>> bytes = 160
>> }
>> arg_from_tty = false
>> key_count = 2
>> record_then_fail = false
>> save_this_command = XIL(0x2aaa8ecfbc50)
>> save_this_original_command = XIL(0x2aaa8ecfbc50)
>> save_real_this_command = XIL(0x2aaa8ecfbc50)
>> save_last_command = XIL(0)
>> prefix_arg = XIL(0)
>> enable = XIL(0)
>> up_event = XIL(0)
>> form = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> specs = XIL(0)
>> sa_avail = <optimized out>
>> sa_count = {
>> bytes = <optimized out>
>> }
>> string_len = <optimized out>
>> string = <optimized out>
>> string_end = <optimized out>
>> next_event = <optimized out>
>> nargs = <optimized out>
>> args = <optimized out>
>> visargs = <optimized out>
>> varies = <optimized out>
>> tem = <optimized out>
>> #59 0x00007ffff27ee8f5 in
> F636f6d6d616e642d65786563757465_command_execute_0 () at
> /home/grfz/src/emacs-igc/src/../native-lisp/31.0.50-b708ad23/preloaded/simple-fab5b0cf-f25e9023.eln
>> #60 0x000055555581b7c7 in funcall_subr (subr=0x7fffe139d428, numargs=1, args=<optimized out>) at ./src/eval.c:3173
>> argbuf = {XIL(0x2aaa8ecfbc50), XIL(0), XIL(0), XIL(0), XIL(0x7fffffffcc90), XIL(0x555555817e73), XIL(0x7ffff287dce0), XIL(0x55555581cf4d)}
>> a = <optimized out>
>> maxargs = 4
>> #61 0x0000555555817e73 in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffcd60) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #62 0x000055555577666c in command_loop_1 () at ./src/keyboard.c:1556
>> cmd = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> keybuf = {XIL(0x2aaa8c649708), make_fixnum(106), make_fixnum(106),
> make_fixnum(97), XIL(0x7fffe1e302e4), XIL(0x7fffe11e2f64),
> XIL(0x7fffe11e2f64), XIL(0x16c00), XIL(0x38), XIL(0x7fffe0ab759d),
> XIL(0x7fffe0ab759d), XIL(0x7fffffffceb0), XIL(0), XIL(0), XIL(0),
> make_fixnum(23456248787193), make_fixnum(0), XIL(0x5555557ff930),
> XIL(0), XIL(0x5555557ff588), XIL(0), XIL(0x5eb92b3c6c43c900), XIL(0),
> XIL(0x60), XIL(0x7fffe582e41b), XIL(0), XIL(0x5555559d4f50),
> XIL(0x7fffe0c6bec5), XIL(0x7fffffffced0), XIL(0x555555817b23)}
>> i = <optimized out>
>> last_pt = 1
>> prev_modiff = 1
>> prev_buffer = 0x7fffe0c6bec0
>> #63 0x0000555555815d26 in internal_condition_case
> (bfun=bfun <at> entry=0x5555557760b0 <command_loop_1>,
> handlers=handlers <at> entry=XIL(0xa8), hfun=hfun <at> entry=0x55555575a510
> <cmd_error>) at ./src/eval.c:1618
>> val = XIL(0x4c)
>> c = 0x7fffe1e5de70
>> #64 0x0000555555758e1e in command_loop_2 (handlers=handlers <at> entry=XIL(0xa8)) at ./src/keyboard.c:1174
>> #65 0x0000555555815aaf in internal_catch
> (tag=tag <at> entry=XIL(0x15460), func=func <at> entry=0x555555758df0
> <command_loop_2>, arg=Python Exception <class 'gdb.error'>: value has
> been optimized out
>> , arg <at> entry=XIL(0xa8)) at ./src/eval.c:1297
>> val = XIL(0x4c)
>> c = 0x7fffe1e37138
>> #66 0x0000555555758db9 in command_loop () at ./src/lisp.h:1240
>> #67 0x0000555555765535 in recursive_edit_1 () at ./src/keyboard.c:760
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #68 0x00005555557658d5 in Frecursive_edit () at ./src/keyboard.c:843
>> #69 0x00005555555cffe5 in main (argc=5, argv=<optimized out>) at ./src/emacs.c:2646
>> stack_bottom_variable = 0x7ffff3e92c60
>> old_argc = <optimized out>
>> no_loadup = <optimized out>
>> junk = 0x0
>> dname_arg = 0x7fffffffd7a8 "EMACS-MPS=yes"
>> ch_to_dir = 0x0
>> original_pwd = <optimized out>
>> dump_mode = <optimized out>
>> skip_args = 1
>> temacs = 0x0
>> attempt_load_pdump = <optimized out>
>> only_version = <optimized out>
>> rlim = {
>> rlim_cur = 10022912,
>> rlim_max = 18446744073709551615
>> }
>> lc_all = <optimized out>
>> sockfd = <optimized out>
>> module_assertions = <optimized out>
>>
>> Lisp Backtrace:
>>
>> eval.c:118: Emacs fatal error: assertion failed: pdl->kind == SPECPDL_BACKTRACE
>>
>> Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
>> 432 {
>> The program being debugged stopped while in a function called from GDB.
>> Evaluation of the expression containing the function
>> (backtrace_function) will be abandoned.
>> When the function is done executing, GDB will silently stop.
>>
>>
>>
>> HTH, Gregor
>
> I'm wondering what should have been the specpdl entry. This one?
>
> #26 0x00007fffde1bc131 in
> F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_38 () at
> /home/grfz/.config/emacs/eln-cache/31.0.50-b708ad23/org-element-1d23d6e0-0b03f1c0.eln
>
> The rest, I think, is die -> backtrace -> assert -> die -> backtrace -> assert ... until it
> stops. Weird.
I think that's the new stackframes gdb created after the crash, trying to
print xbacktrace repeatedly. The real crash starts at #20.
Can you try "p $rsp"?
Pip
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Thu, 09 Jan 2025 22:30:12 GMT) Full text and rfc822 format available.Message #29 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gregor Zattler <telegraph <at> gmx.net> To: Pip Cet <pipcet <at> protonmail.com>, Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Thu, 09 Jan 2025 23:29:07 +0100
Hi Pip,
* Pip Cet <pipcet <at> protonmail.com> [2025-01-09; 19:27 GMT]:
[... 29 Zeilen deleted ...]
> "deadl", which appears at the beginning of an Emacs string ("deadline") only in
> org-agenda.el. The string is unlikely to start earlier because the next
> byte would be 0x08, an ASCII backspace. Unlikely.
>
> More likely it's an unaligned string. I think Emacs string data is
> always aligned, except for pure strings. But on scratch/igc, even pure
> strings are aligned to an 8-byte boundary!
>
> "closed" also appears in org-agenda.el, but this string isn't
> NUL-terminated: it's a Pascal-style string, with a length byte (0x06)
> followed by 6 ASCII characters. That would match the 8-byte "deadline"
> literal.
>
> Possibly a (basic) compression format, probably lz4 or zlib. I'm
> guessing this is a git object, which is stored in zlib format, and that
> appears to use length-prefixed string literals like these.
>
> What is it doing in your Emacs data?
I have no idea. If I remember
correctly, I started Emacs and told it
to load the org-agenda files, and that
would be it, these are plain text.
I do every day at least once. This did
not happen before. I tried to reproduce
in an Emacs optimized for debugging, but
the problem did not occur.
[... 392 Zeilen deleted ...]
> Can you try "p $rsp"?
(gdb) p $rs
$7 = void
Upps, "rs" != "rsp"
(gdb) p $rsp
$10 = (void *) 0x7fffffff95f8
Ciao; Gregor
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 04:53:02 GMT) Full text and rfc822 format available.Message #32 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Gregor Zattler <telegraph <at> gmx.net>, Eli Zaretskii <eliz <at> gnu.org>, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 05:52:39 +0100
Pip Cet <pipcet <at> protonmail.com> writes: > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > >>> #0 terminate_due_to_signal (sig=sig <at> entry=6, > backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 >>> #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 >> "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 >> "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377 >>> #2 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118 >>> #3 0x00007fffffff986f in <function called from gdb> () Another thing that irritates me is that I don't see emacs_backtrace in the bt. Die is there, which calls terminate_due_to_signal, but then we are immediately in backtrace_function. That makes no sense.
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 07:16:01 GMT) Full text and rfc822 format available.Message #35 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: pipcet <at> protonmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 09:15:37 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Gregor Zattler <telegraph <at> gmx.net>, Eli Zaretskii <eliz <at> gnu.org>,
> 75459 <at> debbugs.gnu.org
> Date: Fri, 10 Jan 2025 05:52:39 +0100
>
> Pip Cet <pipcet <at> protonmail.com> writes:
>
> > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >
>
> >>> #0 terminate_due_to_signal (sig=sig <at> entry=6,
> > backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> >>> #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0
> >> "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540
> >> "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377
> >>> #2 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118
> >>> #3 0x00007fffffff986f in <function called from gdb> ()
>
> Another thing that irritates me is that I don't see emacs_backtrace in
> the bt. Die is there, which calls terminate_due_to_signal, but then we
> are immediately in backtrace_function. That makes no sense.
I think that's because we stopped before the call to emacs_backtrace:
> Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> 432 {
> #0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432
> #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h", line=line <at> entry=597) at ./src/alloc.c:8377
This happens because src/.gdbinit sets a breakpoint there:
# When debugging, it is handy to be able to "return" from
# terminate_due_to_signal when an assertion failure is non-fatal.
break terminate_due_to_signal
The call to emacs_backtrace is further down in
terminate_due_to_signal. It was not called yet.
The xbacktrace command is automatically called by GDB as a post-hook
of the "bt" (backtrace) command. So when the functions called by GDB
to generate the Lisp backtrace crash, you see more calls to
terminate_due_to_signal, which again hit the above breakpoint.
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 07:30:02 GMT) Full text and rfc822 format available.Message #38 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: pipcet <at> protonmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 08:29:21 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:
> The xbacktrace command is automatically called by GDB as a post-hook
> of the "bt" (backtrace) command. So when the functions called by GDB
> to generate the Lisp backtrace crash, you see more calls to
> terminate_due_to_signal, which again hit the above breakpoint.
Ah, that explains it, thanks! Didn't know about that hook.
Could the problem then perhaps be barriers? In emacs_lldb.py I have, for
LLDB, a command
def xpostmortem(debugger, command, ctx, result, internal_dict):
"""Call igc_postmortem to set MPS arena to postmortem state"""
debugger.HandleCommand(f"expr igc_postmortem()")
I call that command manually when MPS gets in the way. Here is the
description from MPS
void mps_arena_postmortem(mps_arena_t arena)?
Put an arena into the postmortem state.
arena is the arena.
In the postmortem state, incremental collection does not take place,
objects do not move in memory, references do not change, the staleness
of location dependencies does not change, and memory occupied by
unreachable objects is not recycled. Additionally, all memory protection
is removed, and memory may be in an inconsistent state.
Warning
After calling this function, memory managed by the arena is not in a
consistent state, and so it is no longer safe to continue running the
client program. This function is intended for postmortem debugging only.
This function must be called from the thread that holds the arena lock
(if any thread holds it). This is the case if the program is
single-threaded, or if it is called from an MPS assertion handler. When
calling this function from the debugger, check the stack to see which
thread has the MPS arena lock.
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 07:54:01 GMT) Full text and rfc822 format available.Message #41 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: pipcet <at> protonmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 09:53:11 +0200
> From: Gerd Möllmann <gerd.moellmann <at> gmail.com> > Cc: pipcet <at> protonmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org > Date: Fri, 10 Jan 2025 08:29:21 +0100 > > Could the problem then perhaps be barriers? In emacs_lldb.py I have, for > LLDB, a command > > def xpostmortem(debugger, command, ctx, result, internal_dict): > """Call igc_postmortem to set MPS arena to postmortem state""" > debugger.HandleCommand(f"expr igc_postmortem()") > > I call that command manually when MPS gets in the way. Here is the > description from MPS Maybe. We could add that to the xbacktrace command. However,... > In the postmortem state, incremental collection does not take place, > objects do not move in memory, references do not change, the staleness > of location dependencies does not change, and memory occupied by > unreachable objects is not recycled. Additionally, all memory protection > is removed, and memory may be in an inconsistent state. > > Warning > > After calling this function, memory managed by the arena is not in a > consistent state, and so it is no longer safe to continue running the > client program. This function is intended for postmortem debugging only. > This function must be called from the thread that holds the arena lock > (if any thread holds it). This is the case if the program is > single-threaded, or if it is called from an MPS assertion handler. When > calling this function from the debugger, check the stack to see which > thread has the MPS arena lock. ...the above makes me wonder whether calling this unconditionally will shoot us in the foot. Debugging with GDB does sometimes call functions in the debuggee, whereas the above says "no longer safe to continue running the client program". I wonder what kind of "postmortem debugging" they had in mind, perhaps only debugging MPS-related code itself? In any case, we should call this function only once per run, and in the context of thread 1. So maybe calling it manually, like you do now, is the best alternative? In which case we should add this to etc/DEBUG, I think.
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 08:16:02 GMT) Full text and rfc822 format available.Message #44 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: pipcet <at> protonmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 09:14:53 +0100
Eli Zaretskii <eliz <at> gnu.org> writes: > > ...the above makes me wonder whether calling this unconditionally will > shoot us in the foot. Debugging with GDB does sometimes call > functions in the debuggee, whereas the above says "no longer safe to > continue running the client program". I wonder what kind of > "postmortem debugging" they had in mind, perhaps only debugging > MPS-related code itself? I've had a number of cases where barriers got in the way of looking around in the Lisp data using LLDB. Say one starts with a list, some car is a symbol, and one looks at the value of the symbol. Something like that. It's not ideal that MPS is dead after xpostmortem, but better than nothing.
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 13:47:02 GMT) Full text and rfc822 format available.Message #47 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 13:46:40 +0000
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > Eli Zaretskii <eliz <at> gnu.org> writes: > >> The xbacktrace command is automatically called by GDB as a post-hook >> of the "bt" (backtrace) command. So when the functions called by GDB >> to generate the Lisp backtrace crash, you see more calls to >> terminate_due_to_signal, which again hit the above breakpoint. > > Ah, that explains it, thanks! Didn't know about that hook. That explains why "backtrace" doesn't show up; it doesn't explain why backtrace_function asserts on data that we previously ensured would be of the right kind. As the stack pointer is nowhere near the data that was clobbered, I have no idea what's going on here. .gdbinit ensures we're looking at a frame with pdl->kind == SPECPDL_BACKTRACE, we call backtrace_function, which is meant to be backtrace_function_body, which easserts the very same thing we just tested, but finds it is no longer true. Maybe backtrace_function is no longer equal to backtrace_function_body, but backtrace_function should be in the .rodata section, which should be protected against modification (but GDB has no problem modifying it, and doesn't even issue a warning when doing so; another GDB bug, IMHO). > Could the problem then perhaps be barriers? In emacs_lldb.py I have, for I don't think so: barriers don't cause SIGABRT (not even when the "barrier" is unknown and MPS gives up; in that case, MPS restores the SIGSEGV handler and raises SIGSEGV again; I think that's an MPS bug, BTW: what MPS should do is to restore the SIGSEGV handler and return from the handler, which will cause the faulting instruction to be re-executed, which will, in turn, call the original SIGSEGV handler with a siginfo structure), and the eassert in backtrace_function accesses the specpdl, which is (unfortunately) an unprotected root. > LLDB, a command > > def xpostmortem(debugger, command, ctx, result, internal_dict): > """Call igc_postmortem to set MPS arena to postmortem state""" > debugger.HandleCommand(f"expr igc_postmortem()") > > I call that command manually when MPS gets in the way. Here is the Does lldb allow you to inspect memory that is behind a barrier? GDB does (which is good), but doesn't warn about it in any way. That is very, very confusing behavior. I think it qualifies as a GDB bug which should be fixed (but the last GDB bug I reported was a +1 on a 20-year-old bug report that was never responded to in any way, so maybe reporting further GDB bugs is a waste of time). I don't think the decision to abort MPS and access the data in whatever (presumably inconsistent) state it was left in is one that should be made automatically, and that applies both to calling Emacs functions and to using GDB commands. If calling backtrace in GDB means we can't continue afterwards, that would be very bad. I think it's already bad that we automatically append the Lisp backtrace to "bt" output. IMHO, "bt" should limit itself to accessing process memory via PTRACE, not call into application code. Making it destroy the Emacs session even when we can get a backtrace would be worse. Pip
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 14:00:02 GMT) Full text and rfc822 format available.Message #50 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Gregor Zattler <telegraph <at> gmx.net>, Eli Zaretskii <eliz <at> gnu.org>, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 13:59:10 +0000
"Gregor Zattler via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes:
> Hi Pip,
> * Pip Cet <pipcet <at> protonmail.com> [2025-01-09; 19:27 GMT]:
> [... 29 Zeilen deleted ...]
Sorry about that; I tried to leave in enough context for my response to
make sense without having to reread the original report.
>> "deadl", which appears at the beginning of an Emacs string ("deadline") only in
>> org-agenda.el. The string is unlikely to start earlier because the next
>> byte would be 0x08, an ASCII backspace. Unlikely.
>>
>> More likely it's an unaligned string. I think Emacs string data is
>> always aligned, except for pure strings. But on scratch/igc, even pure
>> strings are aligned to an 8-byte boundary!
>>
>> "closed" also appears in org-agenda.el, but this string isn't
>> NUL-terminated: it's a Pascal-style string, with a length byte (0x06)
>> followed by 6 ASCII characters. That would match the 8-byte "deadline"
>> literal.
>>
>> Possibly a (basic) compression format, probably lz4 or zlib. I'm
>> guessing this is a git object, which is stored in zlib format, and that
>> appears to use length-prefixed string literals like these.
>>
>> What is it doing in your Emacs data?
>
> I have no idea. If I remember
> correctly, I started Emacs and told it
> to load the org-agenda files, and that
> would be it, these are plain text.
Very strange. We sometimes store .el/.elc files in gzipped form, but
.gz files don't usually contain literal strings contained in the
original (M-x find-file-literally seems to confirm this).
We can see some of your org agenda in the backtrace, so that shouldn't
be it.
> (gdb) p $rsp
> $10 = (void *) 0x7fffffff95f8
Nowhere near the corrupt data. Again, very strange.
Pip
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 14:28:02 GMT) Full text and rfc822 format available.Message #53 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 15:27:36 +0100
Pip Cet <pipcet <at> protonmail.com> writes: > Gerd Möllmann <gerd.moellmann <at> gmail.com> writes: > >> Ah, that explains it, thanks! Didn't know about that hook. > > That explains why "backtrace" doesn't show up; it doesn't explain why > backtrace_function asserts on data that we previously ensured would be of > the right kind. True. >> I call that command manually when MPS gets in the way. Here is the > > Does lldb allow you to inspect memory that is behind a barrier? No, or at least I don't know how I could do that. (LLDB's Python API, which I use, is a SWIG wrapper of the C++ objects the lldb lib uses. The Python classes are not completely documented, so there might be something hidden somewhere.)
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 14:46:01 GMT) Full text and rfc822 format available.Message #56 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: gerd.moellmann <at> gmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 16:44:54 +0200
> Date: Fri, 10 Jan 2025 13:46:40 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > Cc: Eli Zaretskii <eliz <at> gnu.org>, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org > > If calling backtrace in GDB means we can't continue afterwards, that > would be very bad. I think it's already bad that we automatically > append the Lisp backtrace to "bt" output. IMHO, "bt" should limit > itself to accessing process memory via PTRACE, not call into application > code. Making it destroy the Emacs session even when we can get a > backtrace would be worse. Usually, automatically calling xbacktrace is very useful. In cases where it is not, one can disable it, like this: (gdb) define hookpost-backtrace Redefine command "hookpost-backtrace"? (y or n) y Type commands for definition of "hookpost-backtrace". End with a line saying just "end". >end (gdb) (It is also possible to start GDB from a directory other than the Emacs src directory, but then one loses the other conveniencies of our .gdbinit.)
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 14:47:01 GMT) Full text and rfc822 format available.Message #59 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Gerd Möllmann <gerd.moellmann <at> gmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 14:46:40 +0000
Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> Ah, that explains it, thanks! Didn't know about that hook.
>>
>> That explains why "backtrace" doesn't show up; it doesn't explain why
>> backtrace_function asserts on data that we previously ensured would be of
>> the right kind.
>
> True.
>
>>> I call that command manually when MPS gets in the way. Here is the
>>
>> Does lldb allow you to inspect memory that is behind a barrier?
>
> No, or at least I don't know how I could do that.
It may have been unfair to call this a GDB bug: I don't know much about
the ptrace API, and if the ptrace API allows modifying rodata and
reading mprotected memory, there's a good chance that's a Linux kernel
bug which isn't present in whatever macOS uses instead.
Speaking of toolchain bugs, though, I appear to have "been" upgraded to
a new GCC version which produces many new warnings, including what
appears to me to be a false positive "null pointer dereference" (NOT a
"potential null pointer dereference") in dispnew.c.
(root_frame () can return a NULL pointer in some contexts, but not in
this one, so this is, at best, a *potential* null pointer dereference,
or a suggested additional assertion. A "null pointer dereference"
without a "potential" is reserved for code paths which can be proven
to dereference a null pointer, not for code paths which cannot be proven
not to. So this is a GCC bug.)
Still investigating the others, but:
In file included from json.c:31:
igc.h:88:7: warning: redundant redeclaration of ‘igc_xnmalloc_ambig’ [-Wredundant-decls]
88 | void *igc_xnmalloc_ambig (ptrdiff_t nitems, ptrdiff_t item_size);
| ^~~~~~~~~~~~~~~~~~
In file included from json.c:28:
lisp.h:6117:14: note: previous declaration of ‘igc_xnmalloc_ambig’ with type ‘void *(ptrdiff_t, ptrdiff_t)’ {aka ‘void *(long int, long int)’}
6117 | extern void *igc_xnmalloc_ambig (ptrdiff_t nitems, ptrdiff_t item_size);
| ^~~~~~~~~~~~~~~~~~
igc.h:90:6: warning: redundant redeclaration of ‘igc_xfree’ [-Wredundant-decls]
90 | void igc_xfree (void *p);
| ^~~~~~~~~
lisp.h:6118:13: note: previous declaration of ‘igc_xfree’ with type ‘void(void *)’
6118 | extern void igc_xfree (void *p);
| ^~~~~~~~~
seems annoying, but avoidable.
I'll push a "fix", but I wanted to explain why first: new useless GCC
warnings force us to do that.
Pip
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 15:29:01 GMT) Full text and rfc822 format available.Message #62 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Gerd Möllmann <gerd.moellmann <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: Eli Zaretskii <eliz <at> gnu.org>, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 16:27:53 +0100
Pip Cet <pipcet <at> protonmail.com> writes:
> (root_frame () can return a NULL pointer in some contexts, but not in
> this one, so this is, at best, a *potential* null pointer dereference,
> or a suggested additional assertion. A "null pointer dereference"
> without a "potential" is reserved for code paths which can be proven
> to dereference a null pointer, not for code paths which cannot be proven
> not to. So this is a GCC bug.)
Okay. I think Eli had something similar, some months ago.
> Still investigating the others, but:
>
> In file included from json.c:31:
> igc.h:88:7: warning: redundant redeclaration of ‘igc_xnmalloc_ambig’ [-Wredundant-decls]
> 88 | void *igc_xnmalloc_ambig (ptrdiff_t nitems, ptrdiff_t item_size);
> | ^~~~~~~~~~~~~~~~~~
> In file included from json.c:28:
> lisp.h:6117:14: note: previous declaration of ‘igc_xnmalloc_ambig’ with type ‘void *(ptrdiff_t, ptrdiff_t)’ {aka ‘void *(long int, long int)’}
> 6117 | extern void *igc_xnmalloc_ambig (ptrdiff_t nitems, ptrdiff_t item_size);
> | ^~~~~~~~~~~~~~~~~~
> igc.h:90:6: warning: redundant redeclaration of ‘igc_xfree’ [-Wredundant-decls]
> 90 | void igc_xfree (void *p);
> | ^~~~~~~~~
> lisp.h:6118:13: note: previous declaration of ‘igc_xfree’ with type ‘void(void *)’
> 6118 | extern void igc_xfree (void *p);
> | ^~~~~~~~~
>
> seems annoying, but avoidable.
>
> I'll push a "fix", but I wanted to explain why first: new useless GCC
> warnings force us to do that.
Thanks for the explanation.
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 15:31:01 GMT) Full text and rfc822 format available.Message #65 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Eli Zaretskii <eliz <at> gnu.org> Cc: gerd.moellmann <at> gmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 15:30:12 +0000
"Eli Zaretskii" <eliz <at> gnu.org> writes:
>> Date: Fri, 10 Jan 2025 13:46:40 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org
>>
>> If calling backtrace in GDB means we can't continue afterwards, that
>> would be very bad. I think it's already bad that we automatically
>> append the Lisp backtrace to "bt" output. IMHO, "bt" should limit
>> itself to accessing process memory via PTRACE, not call into application
>> code. Making it destroy the Emacs session even when we can get a
>> backtrace would be worse.
>
> Usually, automatically calling xbacktrace is very useful. In cases
Point taken. IIRC, I destroyed a GDB session by calling "bt" on the
wrong thread (which had no Lisp backtrace, but the C backtrace was all
that I was interested in). In hindsight, I should have just fixed that
case in .gdbinit. I wrote a patch to do so, but now I'm no longer sure
it's a good idea:
diff --git a/src/eval.c b/src/eval.c
index b214870984c..8af819bc9dd 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -169,6 +169,18 @@ backtrace_p (union specbinding *pdl)
backtrace_thread_p (struct thread_state *tstate, union specbinding *pdl)
{ return pdl >= tstate->m_specpdl; }
+bool
+backtrace_current_thread_p_body (void)
+{
+ /* GDB may call us on the wrong system thread. It's better not to
+ display a Lisp backtrace automatically in that case. */
+ if (!sys_thread_equal (sys_thread_self (), current_thread->thread_id))
+ return false;
+
+ return true;
+}
+GDB_FUNCPTR (backtrace_current_thread_p, bool, (void));
+
union specbinding *
backtrace_top (void)
{
diff --git a/src/.gdbinit b/src/.gdbinit
index 40c1a6081fe..cc25fce93b5 100644
--- a/src/.gdbinit
+++ b/src/.gdbinit
@@ -1278,11 +1278,13 @@ end
# Show Lisp backtrace after normal backtrace.
define hookpost-backtrace
- set $bt = backtrace_top ()
- if backtrace_p ($bt)
- echo \n
- echo Lisp Backtrace:\n
- xbacktrace
+ if backtrace_current_thread_p ()
+ set $bt = backtrace_top ()
+ if backtrace_p ($bt)
+ echo \n
+ echo Lisp Backtrace:\n
+ xbacktrace
+ end
end
end
The problem is this would make debugging slightly less convenient on
macOS (where MPS exceptions are handled on the "wrong" thread) and
possibly Windows (I don't know what sys_thread_self () does for the
additional threads we use on that system). If there's a risk of losing
valuable backtraces for the redisplay code, for example, we should keep
the automatic backtrace and I'll turn it off locally when creating
additional threads.
> where it is not, one can disable it, like this:
>
> (gdb) define hookpost-backtrace
> Redefine command "hookpost-backtrace"? (y or n) y
> Type commands for definition of "hookpost-backtrace".
> End with a line saying just "end".
> >end
> (gdb)
>
> (It is also possible to start GDB from a directory other than the
> Emacs src directory, but then one loses the other conveniencies of our
> .gdbinit.)
I think the .gdbinit code is extremely useful, and it'd be great if we
could somehow cause it to be sourced for gdb run in other directories,
too. (The main emacs/ directory is pure laziness, but I often cd to
lisp/ when debugging ELC compilation issues, because that's where the
command lines "make" produces will work).
(This is off-topic, but we could make all Makefiles use paths relative
to the emacs root directory, and use "$(MAKE) -f $@/Makefile" rather
than "$(MAKE) -C $@". That would involve rewriting the msdos/ sed
scripts, or dropping the MSDOS port entirely. The same is true for any
major change to the build system, but I think only non-recursive GNU
make is an option worth considering. The "new" make replacements, IMHO,
seem inferior to GNU make in every way but performance. Configure is
unbearably slow on emulated systems, but that's fixable without moving
to some non-GNU nightmare. The actual compilation is okay because we
can parallelize it.)
Pip
bug-gnu-emacs <at> gnu.org:bug#75459; Package emacs.
(Fri, 10 Jan 2025 18:58:01 GMT) Full text and rfc822 format available.Message #68 received at 75459 <at> debbugs.gnu.org (full text, mbox):
From: Eli Zaretskii <eliz <at> gnu.org> To: Pip Cet <pipcet <at> protonmail.com> Cc: gerd.moellmann <at> gmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Fri, 10 Jan 2025 20:56:58 +0200
> Date: Fri, 10 Jan 2025 15:30:12 +0000 > From: Pip Cet <pipcet <at> protonmail.com> > Cc: gerd.moellmann <at> gmail.com, telegraph <at> gmx.net, 75459 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz <at> gnu.org> writes: > > The problem is this would make debugging slightly less convenient on > macOS (where MPS exceptions are handled on the "wrong" thread) and > possibly Windows (I don't know what sys_thread_self () does for the > additional threads we use on that system). You will see that run_thread stores in thread_id the return value of sys_thread_self. Does that answer your question? > > where it is not, one can disable it, like this: > > > > (gdb) define hookpost-backtrace > > Redefine command "hookpost-backtrace"? (y or n) y > > Type commands for definition of "hookpost-backtrace". > > End with a line saying just "end". > > >end > > (gdb) > > > > (It is also possible to start GDB from a directory other than the > > Emacs src directory, but then one loses the other conveniencies of our > > .gdbinit.) > > I think the .gdbinit code is extremely useful, and it'd be great if we > could somehow cause it to be sourced for gdb run in other directories, > too. That's easy" use the 'source' command of GDB: (gdb) source /path/to/emacs/src/.gdbinit > (This is off-topic, but we could make all Makefiles use paths relative > to the emacs root directory, and use "$(MAKE) -f $@/Makefile" rather > than "$(MAKE) -C $@". How can you do that and still support building from a separate build directory?
Pip Cet <pipcet <at> protonmail.com>:Gregor Zattler <telegraph <at> gmx.net>:Message #73 received at 75459-done <at> debbugs.gnu.org (full text, mbox):
From: Pip Cet <pipcet <at> protonmail.com> To: Gregor Zattler <telegraph <at> gmx.net> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 75459-done <at> debbugs.gnu.org Subject: Re: bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 Date: Sat, 01 Feb 2025 23:19:59 +0000
"Gregor Zattler" <telegraph <at> gmx.net> writes: > Hi Pip, > * Pip Cet <pipcet <at> protonmail.com> [2025-01-09; 14:47 GMT]: >> Gregor, can you run "print specpdl_ptr", >> "print *(struct Lisp_String *)0x555557040d50", and "bt full"? > > (gdb) bt full > #0 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 > #1 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377 > #2 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118 > #3 0x00007fffffff986f in <function called from gdb> () > #4 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 > #5 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377 > #6 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118 > #7 0x00007fffffff992f in <function called from gdb> () > #8 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 > #9 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377 > #10 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118 > #11 0x00007fffffff99ef in <function called from gdb> () > #12 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 > #13 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377 > #14 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118 > #15 0x00007fffffff9aaf in <function called from gdb> () > #16 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 > #17 0x00005555555b72db in die (msg=msg <at> entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file <at> entry=0x5555559d4540 "eval.c", line=line <at> entry=118) at ./src/alloc.c:8377 > #18 0x00005555555bcc21 in backtrace_function (pdl=<optimized out>) at ./src/eval.c:118 > #19 0x00007fffffff9b6f in <function called from gdb> () > #20 terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=2147483647) at ./src/emacs.c:432 > #21 0x00005555555b72db in die (msg=msg <at> entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file <at> entry=0x5555559b0565 "character.h", line=line <at> entry=597) at ./src/alloc.c:8377 > #22 0x00005555555b6acd in char_table_translate (obj=Python Exception <class 'gdb.error'>: value has been optimized out > , ch=32) at ./src/character.h:597 Gregor, I'm assuming this bug hasn't reappeared and trust you'll open a new bug or reopen this one should it take this opportunity to reappear. So I'm closing this bug. The backtrace thing can be discussed at some other time; the change is in my tree so won't be totally forgotten. Thanks for the many reports! Pip
Debbugs Internal Request <help-debbugs <at> gnu.org>
to internal_control <at> debbugs.gnu.org.
(Sun, 02 Mar 2025 12:24:23 GMT) Full text and rfc822 format available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.