bug#55832: 28.1; Emacs crashes when using tramp from helm in emacs-29

[Thierry Volpiatto <thievol@posteo.net>]

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


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thievol@posteo.net>
>> 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=<optimized out>) 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=<optimized out>, data=<optimized out>, keyboard_quit=<optimized out>) at eval.c:1820
>   #103099 0x00005555555aabe6 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0x90, data=<optimized out>) at eval.c:1689
>   #103100 0x00005555555aac56 in xsignal (data=<optimized out>, error_symbol=0x90) at lisp.h:4528
>   #103101 xsignal1 (error_symbol=error_symbol@entry=0x90, arg=<optimized out>) at eval.c:1849
>   #103102 0x00005555555aac7c in verror (m=<optimized out>, ap=ap@entry=0x7fffffd158e0) at lisp.h:1162
>   #103103 0x00005555555aad1b in error (m=<optimized out>) 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=<optimized out>) 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 <lispsym+144>
"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 <lispsym+59712>
"string"

-- 
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]