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

[Eli Zaretskii <eliz@gnu.org>]

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