Eli Zaretskii writes: >> From: Thierry Volpiatto >> Cc: larsi@gnus.org, 55832@debbugs.gnu.org >> Date: Thu, 09 Jun 2022 15:18:55 +0000 >> >> > (gdb) thread 1 >> > (gdb) bt >> > >> > You said earlier the backtrace produced by that is huge, so I thought >> > maybe just looking at the immediate cause of the segfault could give >> > us enough info. But now we need to see all of it. >> >> Can't send here by mail it is too big 12.8M with 130303 frames, here a >> link to the output file: >> >> https://gist.github.com/thierryvolpiatto/17ee2c5631d0849e57a794e4663b71a5 > > Thanks. This is definitely a C stack overflow: there are 30 frames > that repeatedly and recursively invoke funcall and apply, like this: > > #103104 0x00005555555ad64e in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=3, args=0x7fffffd15a88) at bytecode.c:503 > #103105 0x00005555557ab8be in Ffuncall (nargs=4, args=0x7fffffd15a80) at eval.c:2953 > #103106 0x00005555557adf70 in Fapply (nargs=3, args=0x7fffef48ef00) at eval.c:2624 > #103107 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=3, args=0x7fffef48ef00) at lisp.h:2182 > #103108 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15be0) at eval.c:2953 > #103109 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48ee28) at eval.c:2624 > #103110 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffef48ee28) at lisp.h:2182 > #103111 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15d30) at eval.c:2953 > #103112 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48ec58) at eval.c:2624 > #103113 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffef48ec58) at lisp.h:2182 > #103114 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15e80) at eval.c:2953 > #103115 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48ea88) at eval.c:2624 > #103116 0x0000555555806e87 in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=2, args=0x7fffef48ea88) at lisp.h:2182 > #103117 0x00005555557ab8be in Ffuncall (nargs=3, args=0x7fffffd15fd0) at eval.c:2953 > #103118 0x00005555557adf70 in Fapply (nargs=2, args=0x7fffef48e8b8) at eval.c:2624 > > followed by 103,000(!) frames where Emacs tries to report an error, > and that signals another error: > > #103092 0x00005555555ad64e in exec_byte_code (fun=0x7fffff6702c0, args_template=140737478333120, nargs=0, args=0x7fffffd15790) at bytecode.c:503 > #103093 0x00005555557ab8be in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x7fffffd15788) at eval.c:2953 > #103094 0x000055555580661c in bcall0 (f=) at bytecode.c:335 > #103095 0x00005555557aae1f in do_one_unbind (unwinding=true, bindflag=SET_INTERNAL_UNBIND, this_binding=0x7fffffd157b0) at eval.c:3591 > #103096 unbind_to (count=..., value=value@entry=0x0) at eval.c:3719 > #103097 0x00005555555aaaf2 in unwind_to_catch (catch=catch@entry=0x555557292c10, type=type@entry=NONLOCAL_EXIT_SIGNAL, value=value@entry=0x55555b3c68a3) at lisp.h:1162 > #103098 0x00005555555aabc7 in signal_or_quit (error_symbol=, data=, keyboard_quit=) at eval.c:1820 > #103099 0x00005555555aabe6 in Fsignal (error_symbol=, error_symbol@entry=0x90, data=) at eval.c:1689 > #103100 0x00005555555aac56 in xsignal (data=, error_symbol=0x90) at lisp.h:4528 > #103101 xsignal1 (error_symbol=error_symbol@entry=0x90, arg=) at eval.c:1849 > #103102 0x00005555555aac7c in verror (m=, ap=ap@entry=0x7fffffd158e0) at lisp.h:1162 > #103103 0x00005555555aad1b in error (m=) at eval.c:2052 > > Try this: > > (gdb) source /path/to/emacs/src/.gdbinit > (gdb) frame 8 > (gdb) p arg2 > (gdb) xtype > (gdb) x... > (gdb) p arg1 > (gdb) xtype > (gdb) x... > (gdb) frame 103105 > (gdb) p args[0] > (gdb) xtype > (gdb) x... > (gdb) p args[1] > (gdb) xtype > (gdb) x... > (gdb) p args[2] > (gdb) xtype > (gdb) x... > (gdb) p args[3] > (gdb) xtype > (gdb) x... > > Each time you type "xtype", GDB will display the Lisp type of the > datum. Please invoke the corresponding x... command: xstring for > Lisp_String, xlist for Lisp_Cons, xsymbol for Lisp_Symbol, etc. -- > these are the lines with "x..." above. (gdb) source /home/thierry/tmp/emacs/src/.gdbinit SIGINT is used by the debugger. Are you sure you want to change it? (y or n) [answered Y; input not from terminal] DISPLAY = :0.0 TERM = xterm-256color Breakpoint 1 at 0x5555555a6b56: file emacs.c, line 420. Breakpoint 2 at 0x5555556ba640: file xterm.c, line 22325. (gdb) frame 8 #8 0x00005555557ac8a3 in call2 (arg2=XIL(0x55555a4b2e83), arg1=XIL(0x90), fn=) at lisp.h:3232 3232 return CALLN (Ffuncall, fn, arg1, arg2); (gdb) p arg2 $1 = XIL(0x55555a4b2e83) (gdb) xtype Lisp_Cons (gdb) xlist No symbol "builtin_lisp_symbol" in current context. (gdb) p arg1 $2 = XIL(0x90) (gdb) xtype Lisp_Symbol (gdb) xsymbol $3 = (struct Lisp_Symbol *) 0x555555cd6cd0 "error" (gdb) frame 103105 #103105 0x00005555557ab8be in Ffuncall (nargs=4, args=0x7fffffd15a80) at eval.c:2953 2953 Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1); (gdb) p args[0] $4 = XIL(0x23a93f0) (gdb) xtype Lisp_Symbol (gdb) xsymbol $5 = (struct Lisp_Symbol *) 0x555558080030 "tramp-file-name-for-operation" (gdb) p args[1] $6 = XIL(0x22fdb90) (gdb) xtype Lisp_Symbol (gdb) xsymbol $7 = (struct Lisp_Symbol *) 0x555557fd47d0 "tramp-get-remote-uid" (gdb) p args[2] $8 = XIL(0x55555a7df8c3) (gdb) xtype Lisp_Cons (gdb) xlist No symbol "builtin_lisp_symbol" in current context. (gdb) p args[3] $9 = XIL(0xe940) (gdb) xtype Lisp_Symbol (gdb) xsymbol $10 = (struct Lisp_Symbol *) 0x555555ce5580 "string" -- Thierry