* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
@ 2025-01-09 11:19 Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 13:03 ` Eli Zaretskii
0 siblings, 1 reply; 21+ messages in thread
From: Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-09 11:19 UTC (permalink / raw)
To: 75459
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
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
[-- Attachment #2: gdb-2025-01-09T11-58-12+01-00.txt --]
[-- Type: text/plain, Size: 23546 bytes --]
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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
432 {
#0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
#1 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h", line=line@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@entry=0x5eb92b3c6c43c900, string1=0x0, string1@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@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@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@entry=1, args=args@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@entry=2, args=args@entry=0x7fffffffcab0) at ./src/eval.c:3099
#37 0x0000555555818478 in Fapply (nargs=nargs@entry=3, args=args@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@entry=2, args=args@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@entry=0x5555557760b0 <command_loop_1>, handlers=handlers@entry=XIL(0xa8), hfun=hfun@entry=0x55555575a510 <cmd_error>) at ./src/eval.c:1618
#44 0x0000555555758e1e in command_loop_2 (handlers=handlers@entry=XIL(0xa8)) at ./src/keyboard.c:1174
#45 0x0000555555815aaf in internal_catch (tag=tag@entry=XIL(0x15460), func=func@entry=0x555555758df0 <command_loop_2>, arg=Python Exception <class 'gdb.error'>: value has been optimized out
, arg@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@entry=6, backtrace_limit=backtrace_limit@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@entry=6, backtrace_limit=backtrace_limit@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.
[-- Attachment #3: Type: text/plain, Size: 9536 bytes --]
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
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 11:19 bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432 Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-09 13:03 ` Eli Zaretskii
2025-01-09 14:34 ` Gerd Möllmann
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2025-01-09 13:03 UTC (permalink / raw)
To: Gregor Zattler, Gerd Möllmann; +Cc: 75459
> 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@gnu.org>
>
> Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> 432 {
> #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h", line=line@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@entry=0x5eb92b3c6c43c900, string1=0x0, string1@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@entry=93825020464468, pos=43986, regs=<optimized out>, stop=<optimized out>) at ./src/regex-emacs.c:4553
bufp->translate is not protected from GC?
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 13:03 ` Eli Zaretskii
@ 2025-01-09 14:34 ` Gerd Möllmann
2025-01-09 14:47 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 14:52 ` Gerd Möllmann
0 siblings, 2 replies; 21+ messages in thread
From: Gerd Möllmann @ 2025-01-09 14:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gregor Zattler, 75459
Eli Zaretskii <eliz@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@gnu.org>
>>
>> Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>> 432 {
>> #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h", line=line@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@entry=0x5eb92b3c6c43c900, string1=0x0,
>> string1@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@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.
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 14:34 ` Gerd Möllmann
@ 2025-01-09 14:47 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 15:32 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 14:52 ` Gerd Möllmann
1 sibling, 1 reply; 21+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-09 14:47 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, Gregor Zattler, 75459
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Eli Zaretskii <eliz@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@gnu.org>
>>>
>>> Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>>> 432 {
>>> #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>>> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde
>>> "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h",
>>> line=line@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@entry=0x5eb92b3c6c43c900, string1=0x0,
>>> string1@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@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
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 14:47 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-09 15:32 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 16:14 ` Gerd Möllmann
0 siblings, 1 reply; 21+ messages in thread
From: Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-09 15:32 UTC (permalink / raw)
To: Pip Cet, Gerd Möllmann; +Cc: Eli Zaretskii, 75459
Hi Pip,
* Pip Cet <pipcet@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
#1 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
#5 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
#9 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
#13 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
#17 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
#21 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h", line=line@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@entry=0x5eb92b3c6c43c900, string1=0x0, string1@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@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@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@entry=1, args=args@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@entry=2, args=args@entry=0x7fffffffcab0) at ./src/eval.c:3099
val = Python Exception <class 'gdb.error'>: value has been optimized out
#57 0x0000555555818478 in Fapply (nargs=nargs@entry=3, args=args@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@entry=2, args=args@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@entry=0x5555557760b0 <command_loop_1>, handlers=handlers@entry=XIL(0xa8), hfun=hfun@entry=0x55555575a510 <cmd_error>) at ./src/eval.c:1618
val = XIL(0x4c)
c = 0x7fffe1e5de70
#64 0x0000555555758e1e in command_loop_2 (handlers=handlers@entry=XIL(0xa8)) at ./src/keyboard.c:1174
#65 0x0000555555815aaf in internal_catch (tag=tag@entry=XIL(0x15460), func=func@entry=0x555555758df0 <command_loop_2>, arg=Python Exception <class 'gdb.error'>: value has been optimized out
, arg@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@entry=6, backtrace_limit=backtrace_limit@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
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 15:32 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-09 16:14 ` Gerd Möllmann
2025-01-09 19:27 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 1 reply; 21+ messages in thread
From: Gerd Möllmann @ 2025-01-09 16:14 UTC (permalink / raw)
To: Gregor Zattler; +Cc: Pip Cet, Eli Zaretskii, 75459
Gregor Zattler <telegraph@gmx.net> writes:
> Hi Pip,
> * Pip Cet <pipcet@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> #5 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> #9 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> #13 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> #17 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0 "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540 "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> #21 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h", line=line@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@entry=0x5eb92b3c6c43c900, string1=0x0, string1@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@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@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@entry=1, args=args@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@entry=2, args=args@entry=0x7fffffffcab0) at ./src/eval.c:3099
> val = Python Exception <class 'gdb.error'>: value has been optimized out
>
> #57 0x0000555555818478 in Fapply (nargs=nargs@entry=3, args=args@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@entry=2, args=args@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@entry=0x5555557760b0 <command_loop_1>, handlers=handlers@entry=XIL(0xa8), hfun=hfun@entry=0x55555575a510 <cmd_error>) at ./src/eval.c:1618
> val = XIL(0x4c)
> c = 0x7fffe1e5de70
> #64 0x0000555555758e1e in command_loop_2 (handlers=handlers@entry=XIL(0xa8)) at ./src/keyboard.c:1174
> #65 0x0000555555815aaf in internal_catch (tag=tag@entry=XIL(0x15460), func=func@entry=0x555555758df0 <command_loop_2>, arg=Python Exception <class 'gdb.error'>: value has been optimized out
> , arg@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@entry=6, backtrace_limit=backtrace_limit@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.
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 16:14 ` Gerd Möllmann
@ 2025-01-09 19:27 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 22:29 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 4:52 ` Gerd Möllmann
0 siblings, 2 replies; 21+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-09 19:27 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Gregor Zattler, Eli Zaretskii, 75459
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Gregor Zattler <telegraph@gmx.net> writes:
>
>> Hi Pip,
>> * Pip Cet <pipcet@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540
> "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>> #5 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540
> "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>> #9 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540
> "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>> #13 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540
> "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>> #17 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0
> "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540
> "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>> #21 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde
> "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h",
> line=line@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@entry=0x5eb92b3c6c43c900, string1=0x0,
> string1@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@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@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@entry=1, args=args@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@entry=2, args=args@entry=0x7fffffffcab0) at ./src/eval.c:3099
>> val = Python Exception <class 'gdb.error'>: value has been optimized out
>>
>> #57 0x0000555555818478 in Fapply (nargs=nargs@entry=3, args=args@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@entry=2, args=args@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@entry=0x5555557760b0 <command_loop_1>,
> handlers=handlers@entry=XIL(0xa8), hfun=hfun@entry=0x55555575a510
> <cmd_error>) at ./src/eval.c:1618
>> val = XIL(0x4c)
>> c = 0x7fffe1e5de70
>> #64 0x0000555555758e1e in command_loop_2 (handlers=handlers@entry=XIL(0xa8)) at ./src/keyboard.c:1174
>> #65 0x0000555555815aaf in internal_catch
> (tag=tag@entry=XIL(0x15460), func=func@entry=0x555555758df0
> <command_loop_2>, arg=Python Exception <class 'gdb.error'>: value has
> been optimized out
>> , arg@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@entry=6, backtrace_limit=backtrace_limit@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
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 19:27 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-09 22:29 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 13:59 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 4:52 ` Gerd Möllmann
1 sibling, 1 reply; 21+ messages in thread
From: Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-09 22:29 UTC (permalink / raw)
To: Pip Cet, Gerd Möllmann; +Cc: Eli Zaretskii, 75459
Hi Pip,
* Pip Cet <pipcet@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
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 22:29 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-10 13:59 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 21+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-10 13:59 UTC (permalink / raw)
To: Gerd Möllmann, Gregor Zattler, Eli Zaretskii, 75459
"Gregor Zattler via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs@gnu.org> writes:
> Hi Pip,
> * Pip Cet <pipcet@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 19:27 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 22:29 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-10 4:52 ` Gerd Möllmann
2025-01-10 7:15 ` Eli Zaretskii
1 sibling, 1 reply; 21+ messages in thread
From: Gerd Möllmann @ 2025-01-10 4:52 UTC (permalink / raw)
To: Pip Cet; +Cc: Gregor Zattler, Eli Zaretskii, 75459
Pip Cet <pipcet@protonmail.com> writes:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>>> #0 terminate_due_to_signal (sig=sig@entry=6,
> backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
>>> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0
>> "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540
>> "eval.c", line=line@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 4:52 ` Gerd Möllmann
@ 2025-01-10 7:15 ` Eli Zaretskii
2025-01-10 7:29 ` Gerd Möllmann
0 siblings, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2025-01-10 7:15 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: pipcet, telegraph, 75459
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Gregor Zattler <telegraph@gmx.net>, Eli Zaretskii <eliz@gnu.org>,
> 75459@debbugs.gnu.org
> Date: Fri, 10 Jan 2025 05:52:39 +0100
>
> Pip Cet <pipcet@protonmail.com> writes:
>
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
>
> >>> #0 terminate_due_to_signal (sig=sig@entry=6,
> > backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> >>> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559d49e0
> >> "pdl->kind == SPECPDL_BACKTRACE", file=file@entry=0x5555559d4540
> >> "eval.c", line=line@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@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> 432 {
> #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h", line=line@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.
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 7:15 ` Eli Zaretskii
@ 2025-01-10 7:29 ` Gerd Möllmann
2025-01-10 7:53 ` Eli Zaretskii
2025-01-10 13:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 2 replies; 21+ messages in thread
From: Gerd Möllmann @ 2025-01-10 7:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: pipcet, telegraph, 75459
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 7:29 ` Gerd Möllmann
@ 2025-01-10 7:53 ` Eli Zaretskii
2025-01-10 8:14 ` Gerd Möllmann
2025-01-10 13:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2025-01-10 7:53 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: pipcet, telegraph, 75459
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com, telegraph@gmx.net, 75459@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 7:53 ` Eli Zaretskii
@ 2025-01-10 8:14 ` Gerd Möllmann
0 siblings, 0 replies; 21+ messages in thread
From: Gerd Möllmann @ 2025-01-10 8:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: pipcet, telegraph, 75459
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 7:29 ` Gerd Möllmann
2025-01-10 7:53 ` Eli Zaretskii
@ 2025-01-10 13:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 14:27 ` Gerd Möllmann
2025-01-10 14:44 ` Eli Zaretskii
1 sibling, 2 replies; 21+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-10 13:46 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, telegraph, 75459
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 13:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-10 14:27 ` Gerd Möllmann
2025-01-10 14:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 14:44 ` Eli Zaretskii
1 sibling, 1 reply; 21+ messages in thread
From: Gerd Möllmann @ 2025-01-10 14:27 UTC (permalink / raw)
To: Pip Cet; +Cc: Eli Zaretskii, telegraph, 75459
Pip Cet <pipcet@protonmail.com> writes:
> Gerd Möllmann <gerd.moellmann@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.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 14:27 ` Gerd Möllmann
@ 2025-01-10 14:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 15:27 ` Gerd Möllmann
0 siblings, 1 reply; 21+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-10 14:46 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: Eli Zaretskii, telegraph, 75459
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Pip Cet <pipcet@protonmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@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
^ permalink raw reply [flat|nested] 21+ messages in thread* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 14:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-10 15:27 ` Gerd Möllmann
0 siblings, 0 replies; 21+ messages in thread
From: Gerd Möllmann @ 2025-01-10 15:27 UTC (permalink / raw)
To: Pip Cet; +Cc: Eli Zaretskii, telegraph, 75459
Pip Cet <pipcet@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 13:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 14:27 ` Gerd Möllmann
@ 2025-01-10 14:44 ` Eli Zaretskii
2025-01-10 15:30 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
1 sibling, 1 reply; 21+ messages in thread
From: Eli Zaretskii @ 2025-01-10 14:44 UTC (permalink / raw)
To: Pip Cet; +Cc: gerd.moellmann, telegraph, 75459
> Date: Fri, 10 Jan 2025 13:46:40 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, telegraph@gmx.net, 75459@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.)
^ permalink raw reply [flat|nested] 21+ messages in thread
* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-10 14:44 ` Eli Zaretskii
@ 2025-01-10 15:30 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
0 siblings, 0 replies; 21+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-01-10 15:30 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gerd.moellmann, telegraph, 75459
"Eli Zaretskii" <eliz@gnu.org> writes:
>> Date: Fri, 10 Jan 2025 13:46:40 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, telegraph@gmx.net, 75459@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
^ permalink raw reply related [flat|nested] 21+ messages in thread
* bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432
2025-01-09 14:34 ` Gerd Möllmann
2025-01-09 14:47 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-01-09 14:52 ` Gerd Möllmann
1 sibling, 0 replies; 21+ messages in thread
From: Gerd Möllmann @ 2025-01-09 14:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Gregor Zattler, 75459
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Eli Zaretskii <eliz@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@gnu.org>
>>>
>>> Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6,
>>> backtrace_limit=backtrace_limit@entry=2147483647) at
>>> ./src/emacs.c:432
>>> 432 {
>>> #0 terminate_due_to_signal (sig=sig@entry=6,
>>> backtrace_limit=backtrace_limit@entry=2147483647) at
>>> ./src/emacs.c:432
>>> #1 0x00005555555b72db in die (msg=msg@entry=0x5555559cedde
>>> "CHAR_TABLE_P (obj)", file=file@entry=0x5555559b0565 "character.h",
>>> line=line@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@entry=0x5eb92b3c6c43c900, string1=0x0,
>>> string1@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@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.
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2025-01-10 15:30 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-01-09 11:19 bug#75459: 31.0.50; scratch-igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=2147483647) at ./src/emacs.c:432 Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 13:03 ` Eli Zaretskii
2025-01-09 14:34 ` Gerd Möllmann
2025-01-09 14:47 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 15:32 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 16:14 ` Gerd Möllmann
2025-01-09 19:27 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 22:29 ` Gregor Zattler via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 13:59 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 4:52 ` Gerd Möllmann
2025-01-10 7:15 ` Eli Zaretskii
2025-01-10 7:29 ` Gerd Möllmann
2025-01-10 7:53 ` Eli Zaretskii
2025-01-10 8:14 ` Gerd Möllmann
2025-01-10 13:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 14:27 ` Gerd Möllmann
2025-01-10 14:46 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-10 15:27 ` Gerd Möllmann
2025-01-10 14:44 ` Eli Zaretskii
2025-01-10 15:30 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-01-09 14:52 ` Gerd Möllmann
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.