bug#48252: 28.0.50; Emacs crashes while printing an error message

bug#48252: 28.0.50; Emacs crashes while printing an error message

[Eli Zaretskii]

> From: andrei.elkin@pp.inet.fi
> Date: Wed, 05 May 2021 16:26:05 +0300
> 
> If I grasped the idea right (I had to `p "$xcdr-result"` at two point below)
> `data` looks to be a list of three:
> 
> 
> (gdb) p data
> $46 = XIL(0x5555707ca923)
> (gdb) xcar
> $47 = 0xfd50
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $48 = (struct Lisp_Symbol *) 0x555555ef6810 <lispsym+64848>
> "wrong-type-argument"
> 
> (gdb) p data
> $50 = XIL(0x5555707ca923)
> (gdb) xcdr
> $51 = 0x5555707ca953
> (gdb) xtype
> Lisp_Cons
> 
> 
> (gdb) xcar
> $52 = 0x9990
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $53 = (struct Lisp_Symbol *) 0x555555ef0450 <lispsym+39312>
> "listp"
> (gdb) p $51
> $54 = XIL(0x5555707ca953)
> (gdb) xcdr
> $55 = 0x5555707ca983
> (gdb) xtype
> Lisp_Cons
> 
> 
> (gdb) xcar
> $56 = 0x555576f260a0
> (gdb) xtype
> Lisp_Symbol
> (gdb) xsymbol
> $57 = (struct Lisp_Symbol *) 0xaaaacce0cb60
> Cannot access memory at address 0xaaaacce0cb68
> (gdb) p $55
> $58 = XIL(0x5555707ca983)
> (gdb) xcdr
> $59 = 0x0

Thanks.  Unfortunately, this is not helpful enough.  All it says is
that Emacs tried to display an error message about some object not
being a list, where the offending object is actually an invalid Lisp
object.  And the Lisp backtrace strangely omits several call frames
that I'd expect to see, based on the C backtrace, which also doesn't
help.

Can you please go to the C call-stack frames displayed by GDB, and
manually show the Lisp functions called there?  Given the backtrace I
reproduce below, I'd be interested in frames 15, 10, and 7, with the
following commands:

 (gdb) fr 15
 (gdb) pp fn
 (gdb) pp arg2
 (gdb) pp arg3
 (gdb) fr 10
 (gdb) p nargs
 (gdb) p args[0]
 (gdb) xtype
 (gdb) xSOMETHING
 (gdb) p args[1]
 (gdb) xtype
 (gdb) xSOMETHING
 (gdb) p args[2]
 (gdb) xtype
 (gdb) xSOMETHING
 (gdb) fr 7
 (gdb) p args[0]
 (gdb) xtype
 (gdb) xSOMETHING
 (gdb) p args[1]
 (gdb) xtype
 (gdb) xSOMETHING
 (gdb) p args[2]
 (gdb) xtype
 (gdb) xSOMETHING
 (gdb) p args[3]
 (gdb) xtype
 (gdb) xSOMETHING

where xSOMETHING means some "x" command according to what "xtype"
says.

> >> Lisp Backtrace:
> >> "command-error-default-function" (0xffffb5d8)
> >> "apply" (0xffffb7a8)
> >> 0xea3bf4d8 PVEC_COMPILED
> >> "read-from-minibuffer" (0xffffc1e0)
> >> "query-replace-read-to" (0xffffc708)
> >> "query-replace-read-args" (0xffffcc20)
> >> "byte-code" (0xffffd0d0)
> >> "call-interactively" (0xffffd500)
> >> "command-execute" (0xffffda58)
> >
> > According to this, the command which triggered the problem was
> > something about query-replace, not related to subprocesses.  So this
> > is a different bug, like I assumed.
> 
> It was query-replace, I also remember that. There might be two
> background activities at that moment: autosaving and lsp's
> 
>  lsp-completion-enable-additional-text-edit related
> 
> work (to fix my buffer's white spaces that I found out after restart [in
> another gdb session]).

Maybe the information I requested above will provide some hints.

If even that doesn't help, I'm afraid the only way forward would be to
provide a recipe for reproducing the problem, or maybe you could
pinpoint the top-level function call that injects an invalid Lisp
object.

And it's no longer a good idea for us to continue discussing this in
private, so I'm redirecting this to the bug tracker, and appending
below the last backtrace you sent.

> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
> 0x00005555557e252c in SYMBOL_NAME (sym=XIL(0x555576f260a0)) at lisp.h:2208
> 2208	  return XSYMBOL (sym)->u.s.name;
> (gdb) bt
> #0  0x00005555557e252c in SYMBOL_NAME (sym=XIL(0x555576f260a0)) at lisp.h:2208
> #1  0x00005555557eafd0 in print_object (obj=XIL(0x555576f260a0), printcharfun=XIL(0x30), escapeflag=true) at print.c:2072
> #2  0x00005555557e81c5 in print (obj=XIL(0x555576f260a0), printcharfun=XIL(0x30), escapeflag=true) at print.c:1145
> #3  0x00005555557e59ed in Fprin1 (object=XIL(0x555576f260a0), printcharfun=XIL(0x30)) at print.c:651
> #4  0x00005555557e7c45 in print_error_message (data=XIL(0x5555707ca923), stream=XIL(0x30), context=0x7fffea402143 "", caller=XIL(0x74d0)) at print.c:977
> #5  0x00005555556f9ba9 in Fcommand_error_default_function (data=XIL(0x5555707ca923), context=XIL(0x7fffe9d11524), signal=XIL(0x74d0)) at keyboard.c:1032
> #6  0x00005555557bb5a4 in funcall_subr (subr=0x555555e6c5a0 <Scommand_error_default_function>, numargs=3, args=0x7fffffffb5d8) at eval.c:3116
> #7  0x00005555557bb0f6 in Ffuncall (nargs=4, args=0x7fffffffb5d0) at eval.c:3036
> #8  0x00005555557ba356 in Fapply (nargs=2, args=0x7fffffffb7a8) at eval.c:2666
> #9  0x00005555557bb452 in funcall_subr (subr=0x555555e74420 <Sapply>, numargs=2, args=0x7fffffffb7a8) at eval.c:3091
> #10 0x00005555557bb0f6 in Ffuncall (nargs=3, args=0x7fffffffb7a0) at eval.c:3036
> #11 0x000055555580ac6d in exec_byte_code (bytestr=XIL(0x7fffe9d2d374), vector=XIL(0x7fffea3bf50d), maxdepth=make_fixnum(5), args_template=make_fixnum(128), nargs=3, args=0x7fffffffbc78) at bytecode.c:632
> #12 0x00005555557bb80b in fetch_and_exec_byte_code (fun=XIL(0x7fffea3bf4dd), syms_left=make_fixnum(128), nargs=3, args=0x7fffffffbc78) at eval.c:3160
> #13 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffea3bf4dd), nargs=3, arg_vector=0x7fffffffbc78) at eval.c:3241
> #14 0x00005555557bb14a in Ffuncall (nargs=4, args=0x7fffffffbc70) at eval.c:3040
> #15 0x00005555557baa4e in call3 (fn=XIL(0x7fffea3bf4dd), arg1=XIL(0x5555707ca923), arg2=XIL(0x7fffe9d11524), arg3=XIL(0x74d0)) at eval.c:2910
> #16 0x00005555556f9a33 in cmd_error_internal (data=XIL(0x5555707ca923), context=0x7fffffffbd10 "") at keyboard.c:987
> #17 0x00005555556f991e in cmd_error (data=XIL(0x5555707ca923)) at keyboard.c:956
> #18 0x00005555557b73c0 in internal_condition_case (bfun=0x5555556fa049 <command_loop_1>, handlers=XIL(0x90), hfun=0x5555556f979a <cmd_error>) at eval.c:1471
> #19 0x00005555556f9d0e in command_loop_2 (ignore=XIL(0)) at keyboard.c:1094
> #20 0x00005555557b6a22 in internal_catch (tag=XIL(0x61e0), func=0x5555556f9ce1 <command_loop_2>, arg=XIL(0)) at eval.c:1198
> #21 0x00005555556f9c3c in command_loop () at keyboard.c:1065
> #22 0x00005555556f9369 in recursive_edit_1 () at keyboard.c:720
> #23 0x000055555574234d in read_minibuf (map=XIL(0x7fffe9d1620b), initial=XIL(0), prompt=XIL(0x55557cb10434), expflag=false, histvar=XIL(0x2aaa93f69bb8), histpos=make_fixnum(0), defalt=XIL(0x55558dcc1244), allow_props=false, inherit_input_method=true) at minibuf.c:870
> #24 0x000055555574354f in Fread_from_minibuffer (prompt=XIL(0x55557cb10434), initial_contents=XIL(0), keymap=XIL(0x7fffe9d1620b), read=XIL(0), hist=XIL(0x2aaa93f69bb8), default_value=XIL(0x55558dcc1244), inherit_input_method=XIL(0x30)) at minibuf.c:1318
> #25 0x00005555557bb6d7 in funcall_subr (subr=0x555555e6e7a0 <Sread_from_minibuffer>, numargs=7, args=0x7fffffffc1e0) at eval.c:3131
> #26 0x00005555557bb0f6 in Ffuncall (nargs=8, args=0x7fffffffc1d8) at eval.c:3036
> #27 0x000055555580ac6d in exec_byte_code (bytestr=XIL(0x7fffe9e9b0a4), vector=XIL(0x7fffe9e98505), maxdepth=make_fixnum(12), args_template=make_fixnum(771), nargs=3, args=0x7fffffffc720) at bytecode.c:632
> #28 0x00005555557bb80b in fetch_and_exec_byte_code (fun=XIL(0x7fffe9e984d5), syms_left=make_fixnum(771), nargs=3, args=0x7fffffffc708) at eval.c:3160
> #29 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffe9e984d5), nargs=3, arg_vector=0x7fffffffc708) at eval.c:3241
> #30 0x00005555557bb14a in Ffuncall (nargs=4, args=0x7fffffffc700) at eval.c:3040
> #31 0x000055555580ac6d in exec_byte_code (bytestr=XIL(0x7fffe9ea198c), vector=XIL(0x7fffe9e9f9ed), maxdepth=make_fixnum(12), args_template=make_fixnum(770), nargs=2, args=0x7fffffffcc30) at bytecode.c:632
> #32 0x00005555557bb80b in fetch_and_exec_byte_code (fun=XIL(0x7fffe9e9f9bd), syms_left=make_fixnum(770), nargs=2, args=0x7fffffffcc20) at eval.c:3160
> #33 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffe9e9f9bd), nargs=2, arg_vector=0x7fffffffcc20) at eval.c:3241
> #34 0x00005555557bb14a in Ffuncall (nargs=3, args=0x7fffffffcc18) at eval.c:3040
> #35 0x000055555580ac6d in exec_byte_code (bytestr=XIL(0x7fffe9ea19cc), vector=XIL(0x7fffe9e9f8ed), maxdepth=make_fixnum(8), args_template=XIL(0), nargs=0, args=0x0) at bytecode.c:632
> #36 0x0000555555809fbc in Fbyte_code (bytestr=XIL(0x7fffe9ea19cc), vector=XIL(0x7fffe9e9f8ed), maxdepth=make_fixnum(8)) at bytecode.c:334
> #37 0x00005555557b9ab5 in eval_sub (form=XIL(0x7fffe9e9f8bb)) at eval.c:2517
> #38 0x00005555557b9062 in Feval (form=XIL(0x7fffe9e9f8bb), lexical=XIL(0)) at eval.c:2340
> #39 0x00005555557b19c3 in Fcall_interactively (function=XIL(0x2aaa93fb8c70), record_flag=XIL(0), keys=XIL(0x55557d470145)) at callint.c:334
> #40 0x00005555557bb5a4 in funcall_subr (subr=0x555555e73c60 <Scall_interactively>, numargs=3, args=0x7fffffffd500) at eval.c:3116
> #41 0x00005555557bb0f6 in Ffuncall (nargs=4, args=0x7fffffffd4f8) at eval.c:3036
> #42 0x000055555580ac6d in exec_byte_code (bytestr=XIL(0x7fffe9de36a4), vector=XIL(0x7fffe9de330d), maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=1, args=0x7fffffffda60) at bytecode.c:632
> #43 0x00005555557bb80b in fetch_and_exec_byte_code (fun=XIL(0x7fffe9de32dd), syms_left=make_fixnum(1025), nargs=1, args=0x7fffffffda58) at eval.c:3160
> #44 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffe9de32dd), nargs=1, arg_vector=0x7fffffffda58) at eval.c:3241
> #45 0x00005555557bb14a in Ffuncall (nargs=2, args=0x7fffffffda50) at eval.c:3040
> #46 0x00005555557ba97e in call1 (fn=XIL(0x4560), arg1=XIL(0x2aaa93fb8c70)) at eval.c:2896
> #47 0x00005555556fa897 in command_loop_1 () at keyboard.c:1466
> #48 0x00005555557b73c8 in internal_condition_case (bfun=0x5555556fa049 <command_loop_1>, handlers=XIL(0x90), hfun=0x5555556f979a <cmd_error>) at eval.c:1475
> #49 0x00005555556f9d0e in command_loop_2 (ignore=XIL(0)) at keyboard.c:1094
> #50 0x00005555557b6a22 in internal_catch (tag=XIL(0xe4c0), func=0x5555556f9ce1 <command_loop_2>, arg=XIL(0)) at eval.c:1198
> #51 0x00005555556f9cac in command_loop () at keyboard.c:1073
> #52 0x00005555556f9369 in recursive_edit_1 () at keyboard.c:720
> #53 0x00005555556f94ed in Frecursive_edit () at keyboard.c:789
> #54 0x00005555556f5ce2 in main (argc=2, argv=0x7fffffffdf48) at emacs.c:2297
> 
> Lisp Backtrace:
> "command-error-default-function" (0xffffb5d8)
> "apply" (0xffffb7a8)
> 0xea3bf4d8 PVEC_COMPILED
> "read-from-minibuffer" (0xffffc1e0)
> "query-replace-read-to" (0xffffc708)
> "query-replace-read-args" (0xffffcc20)
> "byte-code" (0xffffd0d0)
> "call-interactively" (0xffffd500)
> "command-execute" (0xffffda58)

Thanks.

bug#48252: 28.0.50; Emacs crashes while printing an error message

[andrei.elkin]

Hello.

I got a stack similar to one of bug48766 and started discussing it with
Eli. Now I am reporting my case and presenting data I collected by Eli's
request.

I run emacs in gdb and it is used crash clearly when I have lsp-mode on.
The last crash with the stack

  >> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
  >> 0x00005555557e252c in SYMBOL_NAME (sym=XIL(0x555576f260a0)) at lisp.h:2208
  >> 2208	  return XSYMBOL (sym)->u.s.name;
  >> (gdb) bt
  >> #0  0x00005555557e252c in SYMBOL_NAME (sym=XIL(0x555576f260a0)) at lisp.h:2208
  >> #1 0x00005555557eafd0 in print_object (obj=XIL(0x555576f260a0),
  >> printcharfun=XIL(0x30), escapeflag=true) at print.c:2072
  >> #2 0x00005555557e81c5 in print (obj=XIL(0x555576f260a0),
  >> printcharfun=XIL(0x30), escapeflag=true) at print.c:1145
  >> #3 0x00005555557e59ed in Fprin1 (object=XIL(0x555576f260a0),
  >> printcharfun=XIL(0x30)) at print.c:651
  >> #4 0x00005555557e7c45 in print_error_message
  >> (data=XIL(0x5555707ca923), stream=XIL(0x30), context=0x7fffea402143
  >> "", caller=XIL(0x74d0)) at print.c:977
  >> #5 0x00005555556f9ba9 in Fcommand_error_default_function
  >> (data=XIL(0x5555707ca923), context=XIL(0x7fffe9d11524),
  >> signal=XIL(0x74d0)) at keyboard.c:1032
  >> #6 0x00005555557bb5a4 in funcall_subr (subr=0x555555e6c5a0
  >> <Scommand_error_default_function>, numargs=3, args=0x7fffffffb5d8)
  >> at eval.c:3116
  >> #7  0x00005555557bb0f6 in Ffuncall (nargs=4, args=0x7fffffffb5d0) at eval.c:3036
  >> #8  0x00005555557ba356 in Fapply (nargs=2, args=0x7fffffffb7a8) at eval.c:2666
  >> #9 0x00005555557bb452 in funcall_subr (subr=0x555555e74420 <Sapply>,
  >> numargs=2, args=0x7fffffffb7a8) at eval.c:3091
  >> #10 0x00005555557bb0f6 in Ffuncall (nargs=3, args=0x7fffffffb7a0) at eval.c:3036
  >> #11 0x000055555580ac6d in exec_byte_code
  >> (bytestr=XIL(0x7fffe9d2d374), vector=XIL(0x7fffea3bf50d),
  >> maxdepth=make_fixnum(5), args_template=make_fixnum(128), nargs=3,
  >> args=0x7fffffffbc78) at bytecode.c:632
  >> #12 0x00005555557bb80b in fetch_and_exec_byte_code
  >> (fun=XIL(0x7fffea3bf4dd), syms_left=make_fixnum(128), nargs=3,
  >> args=0x7fffffffbc78) at eval.c:3160
  >> #13 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffea3bf4dd),
  >> nargs=3, arg_vector=0x7fffffffbc78) at eval.c:3241
  >> #14 0x00005555557bb14a in Ffuncall (nargs=4, args=0x7fffffffbc70) at eval.c:3040
  >> #15 0x00005555557baa4e in call3 (fn=XIL(0x7fffea3bf4dd),
  >> arg1=XIL(0x5555707ca923), arg2=XIL(0x7fffe9d11524),
  >> arg3=XIL(0x74d0)) at eval.c:2910
  >> #16 0x00005555556f9a33 in cmd_error_internal
  >> (data=XIL(0x5555707ca923), context=0x7fffffffbd10 "") at
  >> keyboard.c:987
  >> #17 0x00005555556f991e in cmd_error (data=XIL(0x5555707ca923)) at keyboard.c:956
  >> #18 0x00005555557b73c0 in internal_condition_case
  >> (bfun=0x5555556fa049 <command_loop_1>, handlers=XIL(0x90),
  >> hfun=0x5555556f979a <cmd_error>) at eval.c:1471
  >> #19 0x00005555556f9d0e in command_loop_2 (ignore=XIL(0)) at keyboard.c:1094
  >> #20 0x00005555557b6a22 in internal_catch (tag=XIL(0x61e0),
  >> func=0x5555556f9ce1 <command_loop_2>, arg=XIL(0)) at eval.c:1198
  >> #21 0x00005555556f9c3c in command_loop () at keyboard.c:1065
  >> #22 0x00005555556f9369 in recursive_edit_1 () at keyboard.c:720
  >> #23 0x000055555574234d in read_minibuf (map=XIL(0x7fffe9d1620b),
  >> initial=XIL(0), prompt=XIL(0x55557cb10434), expflag=false,
  >> histvar=XIL(0x2aaa93f69bb8), histpos=make_fixnum(0),
  >> defalt=XIL(0x55558dcc1244), allow_props=false,
  >> inherit_input_method=true) at minibuf.c:870
  >> #24 0x000055555574354f in Fread_from_minibuffer
  >> (prompt=XIL(0x55557cb10434), initial_contents=XIL(0),
  >> keymap=XIL(0x7fffe9d1620b), read=XIL(0), hist=XIL(0x2aaa93f69bb8),
  >> default_value=XIL(0x55558dcc1244), inherit_input_method=XIL(0x30))
  >> at minibuf.c:1318
  >> #25 0x00005555557bb6d7 in funcall_subr (subr=0x555555e6e7a0
  >> <Sread_from_minibuffer>, numargs=7, args=0x7fffffffc1e0) at
  >> eval.c:3131
  >> #26 0x00005555557bb0f6 in Ffuncall (nargs=8, args=0x7fffffffc1d8) at eval.c:3036
  >> #27 0x000055555580ac6d in exec_byte_code
  >> (bytestr=XIL(0x7fffe9e9b0a4), vector=XIL(0x7fffe9e98505),
  >> maxdepth=make_fixnum(12), args_template=make_fixnum(771), nargs=3,
  >> args=0x7fffffffc720) at bytecode.c:632
  >> #28 0x00005555557bb80b in fetch_and_exec_byte_code
  >> (fun=XIL(0x7fffe9e984d5), syms_left=make_fixnum(771), nargs=3,
  >> args=0x7fffffffc708) at eval.c:3160
  >> #29 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffe9e984d5),
  >> nargs=3, arg_vector=0x7fffffffc708) at eval.c:3241
  >> #30 0x00005555557bb14a in Ffuncall (nargs=4, args=0x7fffffffc700) at eval.c:3040
  >> #31 0x000055555580ac6d in exec_byte_code
  >> (bytestr=XIL(0x7fffe9ea198c), vector=XIL(0x7fffe9e9f9ed),
  >> maxdepth=make_fixnum(12), args_template=make_fixnum(770), nargs=2,
  >> args=0x7fffffffcc30) at bytecode.c:632
  >> #32 0x00005555557bb80b in fetch_and_exec_byte_code
  >> (fun=XIL(0x7fffe9e9f9bd), syms_left=make_fixnum(770), nargs=2,
  >> args=0x7fffffffcc20) at eval.c:3160
  >> #33 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffe9e9f9bd),
  >> nargs=2, arg_vector=0x7fffffffcc20) at eval.c:3241
  >> #34 0x00005555557bb14a in Ffuncall (nargs=3, args=0x7fffffffcc18) at eval.c:3040
  >> #35 0x000055555580ac6d in exec_byte_code
  >> (bytestr=XIL(0x7fffe9ea19cc), vector=XIL(0x7fffe9e9f8ed),
  >> maxdepth=make_fixnum(8), args_template=XIL(0), nargs=0, args=0x0) at
  >> bytecode.c:632
  >> #36 0x0000555555809fbc in Fbyte_code (bytestr=XIL(0x7fffe9ea19cc),
  >> vector=XIL(0x7fffe9e9f8ed), maxdepth=make_fixnum(8)) at
  >> bytecode.c:334
  >> #37 0x00005555557b9ab5 in eval_sub (form=XIL(0x7fffe9e9f8bb)) at eval.c:2517
  >> #38 0x00005555557b9062 in Feval (form=XIL(0x7fffe9e9f8bb), lexical=XIL(0)) at eval.c:2340
  >> #39 0x00005555557b19c3 in Fcall_interactively
  >> (function=XIL(0x2aaa93fb8c70), record_flag=XIL(0),
  >> keys=XIL(0x55557d470145)) at callint.c:334
  >> #40 0x00005555557bb5a4 in funcall_subr (subr=0x555555e73c60
  >> <Scall_interactively>, numargs=3, args=0x7fffffffd500) at
  >> eval.c:3116
  >> #41 0x00005555557bb0f6 in Ffuncall (nargs=4, args=0x7fffffffd4f8) at eval.c:3036
  >> #42 0x000055555580ac6d in exec_byte_code
  >> (bytestr=XIL(0x7fffe9de36a4), vector=XIL(0x7fffe9de330d),
  >> maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=1,
  >> args=0x7fffffffda60) at bytecode.c:632
  >> #43 0x00005555557bb80b in fetch_and_exec_byte_code
  >> (fun=XIL(0x7fffe9de32dd), syms_left=make_fixnum(1025), nargs=1,
  >> args=0x7fffffffda58) at eval.c:3160
  >> #44 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffe9de32dd),
  >> nargs=1, arg_vector=0x7fffffffda58) at eval.c:3241
  >> #45 0x00005555557bb14a in Ffuncall (nargs=2, args=0x7fffffffda50) at eval.c:3040
  >> #46 0x00005555557ba97e in call1 (fn=XIL(0x4560), arg1=XIL(0x2aaa93fb8c70)) at eval.c:2896
  >> #47 0x00005555556fa897 in command_loop_1 () at keyboard.c:1466
  >> #48 0x00005555557b73c8 in internal_condition_case
  >> (bfun=0x5555556fa049 <command_loop_1>, handlers=XIL(0x90),
  >> hfun=0x5555556f979a <cmd_error>) at eval.c:1475
  >> #49 0x00005555556f9d0e in command_loop_2 (ignore=XIL(0)) at keyboard.c:1094
  >> #50 0x00005555557b6a22 in internal_catch (tag=XIL(0xe4c0),
  >> func=0x5555556f9ce1 <command_loop_2>, arg=XIL(0)) at eval.c:1198
  >> #51 0x00005555556f9cac in command_loop () at keyboard.c:1073
  >> #52 0x00005555556f9369 in recursive_edit_1 () at keyboard.c:720
  >> #53 0x00005555556f94ed in Frecursive_edit () at keyboard.c:789
  >> #54 0x00005555556f5ce2 in main (argc=2, argv=0x7fffffffdf48) at emacs.c:2297

I received at time I commanded query-replace in the command line.

Then I run few gdb commands by Eli's request to collect the following:




Eli Zaretskii <eliz@gnu.org> writes:

>> From: andrei.elkin@pp.inet.fi
>> Date: Wed, 05 May 2021 16:26:05 +0300
>> 
>> If I grasped the idea right (I had to `p "$xcdr-result"` at two point below)
>> `data` looks to be a list of three:
>> 
>> 
>> (gdb) p data
>> $46 = XIL(0x5555707ca923)
>> (gdb) xcar
>> $47 = 0xfd50
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $48 = (struct Lisp_Symbol *) 0x555555ef6810 <lispsym+64848>
>> "wrong-type-argument"
>> 
>> (gdb) p data
>> $50 = XIL(0x5555707ca923)
>> (gdb) xcdr
>> $51 = 0x5555707ca953
>> (gdb) xtype
>> Lisp_Cons
>> 
>> 
>> (gdb) xcar
>> $52 = 0x9990
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $53 = (struct Lisp_Symbol *) 0x555555ef0450 <lispsym+39312>
>> "listp"
>> (gdb) p $51
>> $54 = XIL(0x5555707ca953)
>> (gdb) xcdr
>> $55 = 0x5555707ca983
>> (gdb) xtype
>> Lisp_Cons
>> 
>> 
>> (gdb) xcar
>> $56 = 0x555576f260a0
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $57 = (struct Lisp_Symbol *) 0xaaaacce0cb60
>> Cannot access memory at address 0xaaaacce0cb68
>> (gdb) p $55
>> $58 = XIL(0x5555707ca983)
>> (gdb) xcdr
>> $59 = 0x0


At this point Eli came up with next set of instructions:

>
> Thanks.  Unfortunately, this is not helpful enough.  All it says is
> that Emacs tried to display an error message about some object not
> being a list, where the offending object is actually an invalid Lisp
> object.  And the Lisp backtrace strangely omits several call frames
> that I'd expect to see, based on the C backtrace, which also doesn't
> help.
>
> Can you please go to the C call-stack frames displayed by GDB, and
> manually show the Lisp functions called there?  Given the backtrace I
> reproduce below, I'd be interested in frames 15, 10, and 7, with the
> following commands:
>
>  (gdb) fr 15
#15 0x00005555557baa4e in call3 (fn=XIL(0x7fffea3bf4dd), arg1=XIL(0x5555707ca923), arg2=XIL(0x7fffe9d11524), arg3=XIL(0x74d0)) at eval.c:2910
2910	  return CALLN (Ffuncall, fn, arg1, arg2, arg3);
>  (gdb) pp fn
#[128 "��\"��\"��" [apply help-command-error-confusable-suggestions command-error-default-function nil] 5 nil]
>  (gdb) pp arg2
""
>  (gdb) pp arg3

funcall-interactively

>  (gdb) fr 10
>  (gdb) p nargs
>  (gdb) p args[0]
>  (gdb) xtype
>  (gdb) xSOMETHING
>  (gdb) p args[1]
>  (gdb) xtype
>  (gdb) xSOMETHING
>  (gdb) p args[2]
>  (gdb) xtype
>  (gdb) xSOMETHING

For the frame 10 this produced for me a list form of

(;; $65
 (;; $66
  (;; $70
   "$72"
   (;; $74
    "Cannot access memory at address 0xaaaacce0cb68" . nil)
   (;; $80
    "$82" . nil))
  (;; $87
   "$89"
   (;; $91
    "$93" . nil)))
 (;; $97
  "$99" ($101 "$103" . nil)))

where `;; $nn` identifies conses, and "$93" - atoms, the log is below:

(gdb) fr 10
#10 0x00005555557bb0f6 in Ffuncall (nargs=3, args=0x7fffffffb7a0) at eval.c:3036
3036	    val = funcall_subr (XSUBR (fun), numargs, args + 1);
(gdb) p nargs 
$60 = 3
(gdb) p args[0]
$61 = XIL(0x2d60)
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol
$62 = (struct Lisp_Symbol *) 0x555555ee9820 <lispsym+11616>
"apply"
(gdb) p args[1]
$63 = XIL(0x2aaa943e6968)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$64 = (struct Lisp_Symbol *) 0x7fffea2cd428
"command-error-default-function"
(gdb) p args[2]
$65 = XIL(0x5555707ca8f3)
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$66 = 0x5555707ca923
(gdb) xtyp
Lisp_Cons
(gdb) xcar 
$67 = 0xfd50
(gdb) xtyp
Lisp_Symbol
(gdb) xsymbol 
$68 = (struct Lisp_Symbol *) 0x555555ef6810 <lispsym+64848>
"wrong-type-argument"
(gdb) p $66
$69 = XIL(0x5555707ca923)
(gdb) xcdr 
$70 = 0x5555707ca953
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$71 = 0x9990
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$72 = (struct Lisp_Symbol *) 0x555555ef0450 <lispsym+39312>
"listp"
(gdb) p $70
$73 = XIL(0x5555707ca953)
(gdb) xcdr 
$74 = 0x5555707ca983
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$75 = 0x555576f260a0
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$76 = (struct Lisp_Symbol *) 0xaaaacce0cb60
Cannot access memory at address 0xaaaacce0cb68
(gdb) p $74
$77 = XIL(0x5555707ca983)
(gdb) xcdr 
$78 = 0x0
(gdb) p $70
$79 = XIL(0x5555707ca953)
(gdb) xcdr 
$80 = 0x5555707ca983
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$81 = 0x555576f260a0
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$82 = (struct Lisp_Symbol *) 0xaaaacce0cb60
Cannot access memory at address 0xaaaacce0cb68
(gdb) p $79
$83 = XIL(0x5555707ca953)
(gdb) p $80
$84 = XIL(0x5555707ca983)
(gdb) xcdr 
$85 = 0x0
(gdb) p $66
$86 = XIL(0x5555707ca923)
(gdb) xtype 
Lisp_Cons
(gdb) xcdr 
$87 = 0x5555707ca953
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$88 = 0x9990
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$89 = (struct Lisp_Symbol *) 0x555555ef0450 <lispsym+39312>
"listp"
(gdb) p $87
$90 = XIL(0x5555707ca953)
(gdb) xcdr 
$91 = 0x5555707ca983
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$92 = 0x555576f260a0
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$93 = (struct Lisp_Symbol *) 0xaaaacce0cb60
Cannot access memory at address 0xaaaacce0cb68
(gdb) p $91
$94 = XIL(0x5555707ca983)
(gdb) xcdr 
$95 = 0x0
(gdb) p $65
$96 = XIL(0x5555707ca8f3)
(gdb) xcdr 
$97 = 0x5555707ca903
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$98 = 0x7fffe9d11524
(gdb) xtype 
Lisp_String
(gdb) xstring
$99 = (struct Lisp_String *) 0x7fffe9d11520
""
(gdb) p $97
$100 = XIL(0x5555707ca903)
(gdb) xcdr 
$101 = 0x5555707ca913
(gdb) xtype
Lisp_Cons
(gdb) xcar 
$102 = 0x74d0
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$103 = (struct Lisp_Symbol *) 0x555555eedf90 <lispsym+29904>
"funcall-interactively"
(gdb) p $101
$104 = XIL(0x5555707ca913)
(gdb) xcdr 
$105 = 0x0


>  (gdb) fr 7
>  (gdb) p args[0]
>  (gdb) xtype
>  (gdb) xSOMETHING
>  (gdb) p args[1]
>  (gdb) xtype
>  (gdb) xSOMETHING
>  (gdb) p args[2]
>  (gdb) xtype
>  (gdb) xSOMETHING
>  (gdb) p args[3]
>  (gdb) xtype
>  (gdb) xSOMETHING

(gdb) fr 7
#7  0x00005555557bb0f6 in Ffuncall (nargs=4, args=0x7fffffffb5d0) at eval.c:3036
3036	    val = funcall_subr (XSUBR (fun), numargs, args + 1);
(gdb) p args[0]
$106 = XIL(0x2aaa943e6968)
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$107 = (struct Lisp_Symbol *) 0x7fffea2cd428
"command-error-default-function"


And for the frame 7'th arg[1]

(;; $108
    "$110"
    (;; $112
        "$114"
        (;; $116
            "$118" . nil)))

here is the rest of the log:

(gdb) p args[1]
$108 = XIL(0x5555707ca923)
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$109 = 0xfd50
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$110 = (struct Lisp_Symbol *) 0x555555ef6810 <lispsym+64848>
"wrong-type-argument"
(gdb) p $108
$111 = XIL(0x5555707ca923)
(gdb) xcdr 
$112 = 0x5555707ca953
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$113 = 0x9990
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$114 = (struct Lisp_Symbol *) 0x555555ef0450 <lispsym+39312>
"listp"
(gdb) p $112
$115 = XIL(0x5555707ca953)
(gdb) xcdr 
$116 = 0x5555707ca983
(gdb) xtype 
Lisp_Cons
(gdb) xcar 
$117 = 0x555576f260a0
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$118 = (struct Lisp_Symbol *) 0xaaaacce0cb60
Cannot access memory at address 0xaaaacce0cb68
(gdb) p $116
$119 = XIL(0x5555707ca983)
(gdb) xcdr 
$120 = 0x0
(gdb) p args[2]
$121 = XIL(0x7fffe9d11524)
(gdb) xtype 
Lisp_String
(gdb) xstring 
$122 = (struct Lisp_String *) 0x7fffe9d11520
""
(gdb) p args[3]
$123 = XIL(0x74d0)
(gdb) xtype 
Lisp_Symbol
(gdb) xsymbol 
$124 = (struct Lisp_Symbol *) 0x555555eedf90 <lispsym+29904>
"funcall-interactively"
(gdb) fr 15
#15 0x00005555557baa4e in call3 (fn=XIL(0x7fffea3bf4dd), arg1=XIL(0x5555707ca923), arg2=XIL(0x7fffe9d11524), arg3=XIL(0x74d0)) at eval.c:2910
2910	  return CALLN (Ffuncall, fn, arg1, arg2, arg3);
(gdb) pp fn
#[128 "��\"��\"��" [apply help-command-error-confusable-suggestions command-error-default-function nil] 5 nil]
(gdb) pp arg2
""
(gdb) pp arg3
funcall-interactively

>
> where xSOMETHING means some "x" command according to what "xtype"
> says.

As a final remark in the report,
I somewhat suspect the whole thing relates to
  lsp-completion-enable-additional-text-edit
and I've turned it to nil in the currently running emacs session.
If I won't see crashes within few days, that would put a heavy blame
onto it :-).

The crashed emacs gdb session is around as well as myself all time if any interests from
the maintainers arise.

Thank you, dear colleagues!

/ndrei

>
>> >> Lisp Backtrace:
>> >> "command-error-default-function" (0xffffb5d8)
>> >> "apply" (0xffffb7a8)
>> >> 0xea3bf4d8 PVEC_COMPILED
>> >> "read-from-minibuffer" (0xffffc1e0)
>> >> "query-replace-read-to" (0xffffc708)
>> >> "query-replace-read-args" (0xffffcc20)
>> >> "byte-code" (0xffffd0d0)
>> >> "call-interactively" (0xffffd500)
>> >> "command-execute" (0xffffda58)
>> >
>> > According to this, the command which triggered the problem was
>> > something about query-replace, not related to subprocesses.  So this
>> > is a different bug, like I assumed.
>> 
>> It was query-replace, I also remember that. There might be two
>> background activities at that moment: autosaving and lsp's
>> 
>>  lsp-completion-enable-additional-text-edit related
>> 
>> work (to fix my buffer's white spaces that I found out after restart [in
>> another gdb session]).
>
> Maybe the information I requested above will provide some hints.
>
> If even that doesn't help, I'm afraid the only way forward would be to
> provide a recipe for reproducing the problem, or maybe you could
> pinpoint the top-level function call that injects an invalid Lisp
> object.
>
> And it's no longer a good idea for us to continue discussing this in
> private, so I'm redirecting this to the bug tracker, and appending
> below the last backtrace you sent.
>
>> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>> 0x00005555557e252c in SYMBOL_NAME (sym=XIL(0x555576f260a0)) at lisp.h:2208
>> 2208	  return XSYMBOL (sym)->u.s.name;
>> (gdb) bt
>> #0  0x00005555557e252c in SYMBOL_NAME (sym=XIL(0x555576f260a0)) at lisp.h:2208
>> #1 0x00005555557eafd0 in print_object (obj=XIL(0x555576f260a0),
>> printcharfun=XIL(0x30), escapeflag=true) at print.c:2072
>> #2 0x00005555557e81c5 in print (obj=XIL(0x555576f260a0),
>> printcharfun=XIL(0x30), escapeflag=true) at print.c:1145
>> #3 0x00005555557e59ed in Fprin1 (object=XIL(0x555576f260a0),
>> printcharfun=XIL(0x30)) at print.c:651
>> #4 0x00005555557e7c45 in print_error_message
>> (data=XIL(0x5555707ca923), stream=XIL(0x30), context=0x7fffea402143
>> "", caller=XIL(0x74d0)) at print.c:977
>> #5 0x00005555556f9ba9 in Fcommand_error_default_function
>> (data=XIL(0x5555707ca923), context=XIL(0x7fffe9d11524),
>> signal=XIL(0x74d0)) at keyboard.c:1032
>> #6 0x00005555557bb5a4 in funcall_subr (subr=0x555555e6c5a0
>> <Scommand_error_default_function>, numargs=3, args=0x7fffffffb5d8)
>> at eval.c:3116
>> #7  0x00005555557bb0f6 in Ffuncall (nargs=4, args=0x7fffffffb5d0) at eval.c:3036
>> #8  0x00005555557ba356 in Fapply (nargs=2, args=0x7fffffffb7a8) at eval.c:2666
>> #9 0x00005555557bb452 in funcall_subr (subr=0x555555e74420 <Sapply>,
>> numargs=2, args=0x7fffffffb7a8) at eval.c:3091
>> #10 0x00005555557bb0f6 in Ffuncall (nargs=3, args=0x7fffffffb7a0) at eval.c:3036
>> #11 0x000055555580ac6d in exec_byte_code
>> (bytestr=XIL(0x7fffe9d2d374), vector=XIL(0x7fffea3bf50d),
>> maxdepth=make_fixnum(5), args_template=make_fixnum(128), nargs=3,
>> args=0x7fffffffbc78) at bytecode.c:632
>> #12 0x00005555557bb80b in fetch_and_exec_byte_code
>> (fun=XIL(0x7fffea3bf4dd), syms_left=make_fixnum(128), nargs=3,
>> args=0x7fffffffbc78) at eval.c:3160
>> #13 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffea3bf4dd),
>> nargs=3, arg_vector=0x7fffffffbc78) at eval.c:3241
>> #14 0x00005555557bb14a in Ffuncall (nargs=4, args=0x7fffffffbc70) at eval.c:3040
>> #15 0x00005555557baa4e in call3 (fn=XIL(0x7fffea3bf4dd),
>> arg1=XIL(0x5555707ca923), arg2=XIL(0x7fffe9d11524),
>> arg3=XIL(0x74d0)) at eval.c:2910
>> #16 0x00005555556f9a33 in cmd_error_internal
>> (data=XIL(0x5555707ca923), context=0x7fffffffbd10 "") at
>> keyboard.c:987
>> #17 0x00005555556f991e in cmd_error (data=XIL(0x5555707ca923)) at keyboard.c:956
>> #18 0x00005555557b73c0 in internal_condition_case
>> (bfun=0x5555556fa049 <command_loop_1>, handlers=XIL(0x90),
>> hfun=0x5555556f979a <cmd_error>) at eval.c:1471
>> #19 0x00005555556f9d0e in command_loop_2 (ignore=XIL(0)) at keyboard.c:1094
>> #20 0x00005555557b6a22 in internal_catch (tag=XIL(0x61e0),
>> func=0x5555556f9ce1 <command_loop_2>, arg=XIL(0)) at eval.c:1198
>> #21 0x00005555556f9c3c in command_loop () at keyboard.c:1065
>> #22 0x00005555556f9369 in recursive_edit_1 () at keyboard.c:720
>> #23 0x000055555574234d in read_minibuf (map=XIL(0x7fffe9d1620b),
>> initial=XIL(0), prompt=XIL(0x55557cb10434), expflag=false,
>> histvar=XIL(0x2aaa93f69bb8), histpos=make_fixnum(0),
>> defalt=XIL(0x55558dcc1244), allow_props=false,
>> inherit_input_method=true) at minibuf.c:870
>> #24 0x000055555574354f in Fread_from_minibuffer
>> (prompt=XIL(0x55557cb10434), initial_contents=XIL(0),
>> keymap=XIL(0x7fffe9d1620b), read=XIL(0), hist=XIL(0x2aaa93f69bb8),
>> default_value=XIL(0x55558dcc1244), inherit_input_method=XIL(0x30))
>> at minibuf.c:1318
>> #25 0x00005555557bb6d7 in funcall_subr (subr=0x555555e6e7a0
>> <Sread_from_minibuffer>, numargs=7, args=0x7fffffffc1e0) at
>> eval.c:3131
>> #26 0x00005555557bb0f6 in Ffuncall (nargs=8, args=0x7fffffffc1d8) at eval.c:3036
>> #27 0x000055555580ac6d in exec_byte_code
>> (bytestr=XIL(0x7fffe9e9b0a4), vector=XIL(0x7fffe9e98505),
>> maxdepth=make_fixnum(12), args_template=make_fixnum(771), nargs=3,
>> args=0x7fffffffc720) at bytecode.c:632
>> #28 0x00005555557bb80b in fetch_and_exec_byte_code
>> (fun=XIL(0x7fffe9e984d5), syms_left=make_fixnum(771), nargs=3,
>> args=0x7fffffffc708) at eval.c:3160
>> #29 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffe9e984d5),
>> nargs=3, arg_vector=0x7fffffffc708) at eval.c:3241
>> #30 0x00005555557bb14a in Ffuncall (nargs=4, args=0x7fffffffc700) at eval.c:3040
>> #31 0x000055555580ac6d in exec_byte_code
>> (bytestr=XIL(0x7fffe9ea198c), vector=XIL(0x7fffe9e9f9ed),
>> maxdepth=make_fixnum(12), args_template=make_fixnum(770), nargs=2,
>> args=0x7fffffffcc30) at bytecode.c:632
>> #32 0x00005555557bb80b in fetch_and_exec_byte_code
>> (fun=XIL(0x7fffe9e9f9bd), syms_left=make_fixnum(770), nargs=2,
>> args=0x7fffffffcc20) at eval.c:3160
>> #33 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffe9e9f9bd),
>> nargs=2, arg_vector=0x7fffffffcc20) at eval.c:3241
>> #34 0x00005555557bb14a in Ffuncall (nargs=3, args=0x7fffffffcc18) at eval.c:3040
>> #35 0x000055555580ac6d in exec_byte_code
>> (bytestr=XIL(0x7fffe9ea19cc), vector=XIL(0x7fffe9e9f8ed),
>> maxdepth=make_fixnum(8), args_template=XIL(0), nargs=0, args=0x0) at
>> bytecode.c:632
>> #36 0x0000555555809fbc in Fbyte_code (bytestr=XIL(0x7fffe9ea19cc),
>> vector=XIL(0x7fffe9e9f8ed), maxdepth=make_fixnum(8)) at
>> bytecode.c:334
>> #37 0x00005555557b9ab5 in eval_sub (form=XIL(0x7fffe9e9f8bb)) at eval.c:2517
>> #38 0x00005555557b9062 in Feval (form=XIL(0x7fffe9e9f8bb), lexical=XIL(0)) at eval.c:2340
>> #39 0x00005555557b19c3 in Fcall_interactively
>> (function=XIL(0x2aaa93fb8c70), record_flag=XIL(0),
>> keys=XIL(0x55557d470145)) at callint.c:334
>> #40 0x00005555557bb5a4 in funcall_subr (subr=0x555555e73c60
>> <Scall_interactively>, numargs=3, args=0x7fffffffd500) at
>> eval.c:3116
>> #41 0x00005555557bb0f6 in Ffuncall (nargs=4, args=0x7fffffffd4f8) at eval.c:3036
>> #42 0x000055555580ac6d in exec_byte_code
>> (bytestr=XIL(0x7fffe9de36a4), vector=XIL(0x7fffe9de330d),
>> maxdepth=make_fixnum(13), args_template=make_fixnum(1025), nargs=1,
>> args=0x7fffffffda60) at bytecode.c:632
>> #43 0x00005555557bb80b in fetch_and_exec_byte_code
>> (fun=XIL(0x7fffe9de32dd), syms_left=make_fixnum(1025), nargs=1,
>> args=0x7fffffffda58) at eval.c:3160
>> #44 0x00005555557bbbbb in funcall_lambda (fun=XIL(0x7fffe9de32dd),
>> nargs=1, arg_vector=0x7fffffffda58) at eval.c:3241
>> #45 0x00005555557bb14a in Ffuncall (nargs=2, args=0x7fffffffda50) at eval.c:3040
>> #46 0x00005555557ba97e in call1 (fn=XIL(0x4560), arg1=XIL(0x2aaa93fb8c70)) at eval.c:2896
>> #47 0x00005555556fa897 in command_loop_1 () at keyboard.c:1466
>> #48 0x00005555557b73c8 in internal_condition_case
>> (bfun=0x5555556fa049 <command_loop_1>, handlers=XIL(0x90),
>> hfun=0x5555556f979a <cmd_error>) at eval.c:1475
>> #49 0x00005555556f9d0e in command_loop_2 (ignore=XIL(0)) at keyboard.c:1094
>> #50 0x00005555557b6a22 in internal_catch (tag=XIL(0xe4c0),
>> func=0x5555556f9ce1 <command_loop_2>, arg=XIL(0)) at eval.c:1198
>> #51 0x00005555556f9cac in command_loop () at keyboard.c:1073
>> #52 0x00005555556f9369 in recursive_edit_1 () at keyboard.c:720
>> #53 0x00005555556f94ed in Frecursive_edit () at keyboard.c:789
>> #54 0x00005555556f5ce2 in main (argc=2, argv=0x7fffffffdf48) at emacs.c:2297
>> 
>> Lisp Backtrace:
>> "command-error-default-function" (0xffffb5d8)
>> "apply" (0xffffb7a8)
>> 0xea3bf4d8 PVEC_COMPILED
>> "read-from-minibuffer" (0xffffc1e0)
>> "query-replace-read-to" (0xffffc708)
>> "query-replace-read-args" (0xffffcc20)
>> "byte-code" (0xffffd0d0)
>> "call-interactively" (0xffffd500)
>> "command-execute" (0xffffda58)
>
> Thanks.

bug#48252: Crashes continue ...

[andrei.elkin]

Salve!

...and what maybe is better that the most recent stack, below, is much shorter.
And I am leaving it alive in case there will be interest or just further
instruction for me.

Thanks for any feedback!


Cheers,

Andrei

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x00005555557e5e10 in SYMBOL_NAME (sym=0x55555d656cb0) at lisp.h:2223
2223	  return XSYMBOL (sym)->u.s.name;
(gdb) bt
#0  0x00005555557e5e10 in SYMBOL_NAME (sym=0x55555d656cb0) at lisp.h:2223
#1  0x00005555557ee8f6 in print_object (obj=0x55555d656cb0, printcharfun=0x30, escapeflag=true) at print.c:2076
#2  0x00005555557ebaeb in print (obj=0x55555d656cb0, printcharfun=0x30, escapeflag=true) at print.c:1149
#3  0x00005555557e92de in Fprin1 (object=0x55555d656cb0, printcharfun=0x30) at print.c:651
#4  0x00005555557eb56b in print_error_message (data=0x55555c5ce293, stream=0x30, context=0x7fffea3e108d "", caller=0x7620) at print.c:981
#5  0x00005555556fbc43 in Fcommand_error_default_function (data=0x55555c5ce293, context=0x7fffe9cb0324, signal=0x7620) at keyboard.c:1070
#6  0x00005555557beb1b in funcall_subr (subr=0x555555e75880 <Scommand_error_default_function>, numargs=3, args=0x7fffffffd448) at eval.c:3148
#7  0x00005555557be66d in Ffuncall (nargs=4, args=0x7fffffffd440) at eval.c:3068
#8  0x00005555557bd8cd in Fapply (nargs=2, args=0x7fffffffd618) at eval.c:2698
#9  0x00005555557be9c9 in funcall_subr (subr=0x555555e7d800 <Sapply>, numargs=2, args=0x7fffffffd618) at eval.c:3123
#10 0x00005555557be66d in Ffuncall (nargs=3, args=0x7fffffffd610) at eval.c:3068
#11 0x000055555580ecd1 in exec_byte_code (bytestr=0x7fffe9ccc484, vector=0x7fffea3950d5, maxdepth=0x16, args_template=0x202, nargs=3, args=0x7fffffffdae8) at bytecode.c:632
#12 0x00005555557bed82 in fetch_and_exec_byte_code (fun=0x7fffea3950a5, syms_left=0x202, nargs=3, args=0x7fffffffdae8) at eval.c:3192
#13 0x00005555557bf132 in funcall_lambda (fun=0x7fffea3950a5, nargs=3, arg_vector=0x7fffffffdae8) at eval.c:3273
#14 0x00005555557be6c1 in Ffuncall (nargs=4, args=0x7fffffffdae0) at eval.c:3072
#15 0x00005555557bdfc5 in call3 (fn=0x7fffea3950a5, arg1=0x55555c5ce293, arg2=0x7fffe9cb0324, arg3=0x7620) at eval.c:2942
#16 0x00005555556fba46 in cmd_error_internal (data=0x55555c5ce293, context=0x7fffffffdb90 "") at keyboard.c:1013
#17 0x00005555556fb913 in cmd_error (data=0x55555c5ce293) at keyboard.c:981
#18 0x00005555557ba88a in internal_condition_case (bfun=0x5555556fc0dd <command_loop_1>, handlers=0x90, hfun=0x5555556fb6de <cmd_error>) at eval.c:1491
#19 0x00005555556fbda2 in command_loop_2 (handlers=0x90) at keyboard.c:1133
#20 0x00005555557b9f6b in internal_catch (tag=0xe9a0, func=0x5555556fbd7b <command_loop_2>, arg=0x90) at eval.c:1226
#21 0x00005555556fbd46 in command_loop () at keyboard.c:1111
#22 0x00005555556fb291 in recursive_edit_1 () at keyboard.c:720
#23 0x00005555556fb431 in Frecursive_edit () at keyboard.c:803
#24 0x00005555556f7c0a in main (argc=2, argv=0x7fffffffdf48) at emacs.c:2345

bug#48252: Crashes continue ...

[Eli Zaretskii]

> From: andrei.elkin@pp.inet.fi
> Date: Thu, 28 Oct 2021 16:38:00 +0300
> 
> ...and what maybe is better that the most recent stack, below, is much shorter.
> And I am leaving it alive in case there will be interest or just further
> instruction for me.

Please invoke xbacktrace and post the results.  (If GDB says it
doesn't know that command, say "source /path/to/emacs/src/.gdbinit"
first.)

bug#48252: Crashes continue ...

[andrei.elkin]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: andrei.elkin@pp.inet.fi
>> Date: Thu, 28 Oct 2021 16:38:00 +0300
>> 
>> ...and what maybe is better that the most recent stack, below, is much shorter.
>> And I am leaving it alive in case there will be interest or just further
>> instruction for me.
>
> Please invoke xbacktrace and post the results.  (If GDB says it
> doesn't know that command, say "source /path/to/emacs/src/.gdbinit"
> first.)

(gdb) xbacktrace 
"command-error-default-function" (0xffffd448)
"apply" (0xffffd618)
0xea3950a0 PVEC_COMPILED

PS. I am not sure about significance of the warning I got:

(gdb) source ./src/.gdbinit 
Warning: /media/local_17/src/emacs/git/emacs/../lwlib: No such file or directory.

bug#48252: Crashes continue ...

[Eli Zaretskii]

> From: andrei.elkin@pp.inet.fi
> Cc: 48252@debbugs.gnu.org
> Date: Fri, 29 Oct 2021 18:08:03 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: andrei.elkin@pp.inet.fi
> >> Date: Thu, 28 Oct 2021 16:38:00 +0300
> >> 
> >> ...and what maybe is better that the most recent stack, below, is much shorter.
> >> And I am leaving it alive in case there will be interest or just further
> >> instruction for me.
> >
> > Please invoke xbacktrace and post the results.  (If GDB says it
> > doesn't know that command, say "source /path/to/emacs/src/.gdbinit"
> > first.)
> 
> (gdb) xbacktrace 
> "command-error-default-function" (0xffffd448)
> "apply" (0xffffd618)
> 0xea3950a0 PVEC_COMPILED

Is that all?  It should be a lot longer.

bug#48252: Crashes continue ...

[Eli Zaretskii]

[Please use Reply All to reply, to keep the bug address CC'ed.]

> From: andrei.elkin@pp.inet.fi
> Date: Fri, 29 Oct 2021 20:19:40 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: andrei.elkin@pp.inet.fi
> >> Cc: 48252@debbugs.gnu.org
> >> Date: Fri, 29 Oct 2021 18:08:03 +0300
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> From: andrei.elkin@pp.inet.fi
> >> >> Date: Thu, 28 Oct 2021 16:38:00 +0300
> >> >> 
> >> >> ...and what maybe is better that the most recent stack, below, is much shorter.
> >> >> And I am leaving it alive in case there will be interest or just further
> >> >> instruction for me.
> >> >
> >> > Please invoke xbacktrace and post the results.  (If GDB says it
> >> > doesn't know that command, say "source /path/to/emacs/src/.gdbinit"
> >> > first.)
> >> 
> >> (gdb) xbacktrace 
> >> "command-error-default-function" (0xffffd448)
> >> "apply" (0xffffd618)
> >> 0xea3950a0 PVEC_COMPILED
> >
> > Is that all?  It should be a lot longer.
> 
> That's all though bt still produces the same stack.

Then you will have to do it manually.  For each stack frame N that
shows a call to Ffuncall, like this:

  #7  0x00005555557be66d in Ffuncall (nargs=4, args=0x7fffffffd440) at eval.c:3068

please do:

  (gdb) frame N
  (gdb) print args[0]
  (gdb) xtype

The last command will usually say "Lisp_Symbol", in which case follow
it with

  (gdb) xsymbol

Also, try this:

  (gdb) frame 17
  (gdb) p data
  (gdb) xtype

The last command will probably say "Lisp_Cons", in which case please
show its cells using the xcar and xcdr commands.

In general, what I see is that some command signaled an error, and the
error data includes some invalid Lisp object.  The challenge is to
find that command and understand what kind of invalid object it
generates.

bug#48252: Crashes continue ...

[Eli Zaretskii]

[Please use Reply All to reply, to keep the bug address CC'ed.]

> From: andrei.elkin@pp.inet.fi
> Date: Fri, 29 Oct 2021 20:19:40 +0300
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: andrei.elkin@pp.inet.fi
> >> Cc: 48252@debbugs.gnu.org
> >> Date: Fri, 29 Oct 2021 18:08:03 +0300
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> From: andrei.elkin@pp.inet.fi
> >> >> Date: Thu, 28 Oct 2021 16:38:00 +0300
> >> >> 
> >> >> ...and what maybe is better that the most recent stack, below, is much shorter.
> >> >> And I am leaving it alive in case there will be interest or just further
> >> >> instruction for me.
> >> >
> >> > Please invoke xbacktrace and post the results.  (If GDB says it
> >> > doesn't know that command, say "source /path/to/emacs/src/.gdbinit"
> >> > first.)
> >> 
> >> (gdb) xbacktrace 
> >> "command-error-default-function" (0xffffd448)
> >> "apply" (0xffffd618)
> >> 0xea3950a0 PVEC_COMPILED
> >
> > Is that all?  It should be a lot longer.
> 
> That's all though bt still produces the same stack.

I've re-read the discussion till now, and I'm afraid this crash
provides no new information that can allow us to make progress.  Once
again, Emacs tries to signal an error, and the error data includes
some invalid object.

As I said earlier, the only way forward is to come up with a
reproducible recipe starting from "emacs -Q", so that I or someone
else could debug it locally.

Or maybe you could figure out which Lisp code is running when this
happens, and show the problematic Lisp.

Sorry I couldn't be of more help.

bug#48252: Crashes continue ...

[andrei.elkin]

Thanks, Eli for looking at it again!

I'll try to reproduce it, I feel I know how to :-), just not sure about
 -Q. Most probably my init file matters critically.

Cheers.

Andrei

>
> I've re-read the discussion till now, and I'm afraid this crash
> provides no new information that can allow us to make progress.  Once
> again, Emacs tries to signal an error, and the error data includes
> some invalid object.
>
> As I said earlier, the only way forward is to come up with a
> reproducible recipe starting from "emacs -Q", so that I or someone
> else could debug it locally.
>
> Or maybe you could figure out which Lisp code is running when this
> happens, and show the problematic Lisp.
>
> Sorry I couldn't be of more help.

bug#48252: Crashes continue ...

[Eli Zaretskii]

> From: andrei.elkin@pp.inet.fi
> Cc: 48252@debbugs.gnu.org
> Date: Sat, 30 Oct 2021 14:07:44 +0300
> 
> Thanks, Eli for looking at it again!
> 
> I'll try to reproduce it, I feel I know how to :-), just not sure about
>  -Q. Most probably my init file matters critically.

That's okay: just make sure your recipe includes loading of minimum
number of packages and the minimal customizations required for
reproducing the problem.

bug#48252: 28.0.50; Emacs crashes while printing an error message

[Lars Ingebrigtsen]

andrei.elkin@pp.inet.fi writes:

> I'll try to reproduce it, I feel I know how to :-), just not sure about
>  -Q. Most probably my init file matters critically.

Andrei, did you make any progress in reproducing this problem (if you
still experience it in recent Emacs versions)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48252: 28.0.50; Emacs crashes while printing an error message

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> I'll try to reproduce it, I feel I know how to :-), just not sure about
>>  -Q. Most probably my init file matters critically.
>
> Andrei, did you make any progress in reproducing this problem (if you
> still experience it in recent Emacs versions)?

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please respond to this email and we'll reopen the bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#48252: Crashes continue ...

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Howdy Eli, Lars.

Just to report that the bug is still alive. It did not come to me back
for a couple of monthes, to wait for today.
I know (quoted) your last time summary, still here is the current trace:


(gdb) bt
#0  0x0000555555850361 in SYMBOL_NAME (sym=...) at lisp.h:2225
#1  0x0000555555859c5b in print_object (obj=..., printcharfun=..., escapeflag=true) at print.c:2083
#2  0x00005555558569b1 in print (obj=..., printcharfun=..., escapeflag=true) at print.c:1156
#3  0x0000555555853ecf in Fprin1 (object=..., printcharfun=...) at print.c:651
#4  0x000055555585641b in print_error_message (data=..., stream=..., context=0x7fffea35f0d2 "", caller=...) at print.c:988
#5  0x0000555555739fe1 in Fcommand_error_default_function (data=..., context=..., signal=...) at keyboard.c:1070
#6  0x0000555555820b97 in funcall_subr (subr=0x555556003720 <Scommand_error_default_function>, numargs=3, args=0x7fffffffd428) at eval.c:3103
#7  0x00005555558205a8 in Ffuncall (nargs=4, args=0x7fffffffd420) at eval.c:3023
#8  0x000055555581f664 in Fapply (nargs=2, args=0x7fffffffd5f8) at eval.c:2653
#9  0x0000555555820a1a in funcall_subr (subr=0x55555600b660 <Sapply>, numargs=2, args=0x7fffffffd5f8) at eval.c:3078
#10 0x00005555558205a8 in Ffuncall (nargs=3, args=0x7fffffffd5f0) at eval.c:3023
#11 0x000055555587e81b in exec_byte_code (bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=3, args=0x7fffffffdab8) at bytecode.c:632
#12 0x0000555555820def in fetch_and_exec_byte_code (fun=..., syms_left=..., nargs=3, args=0x7fffffffdab8) at eval.c:3147
#13 0x0000555555821298 in funcall_lambda (fun=..., nargs=3, arg_vector=0x7fffffffdab8) at eval.c:3228
#14 0x00005555558205fc in Ffuncall (nargs=4, args=0x7fffffffdab0) at eval.c:3027
#15 0x000055555581fe8d in call3 (fn=..., arg1=..., arg2=..., arg3=...) at eval.c:2897
#16 0x0000555555739d4e in cmd_error_internal (data=..., context=0x7fffffffdb60 "") at keyboard.c:1013
#17 0x0000555555739bf1 in cmd_error (data=...) at keyboard.c:981
#18 0x000055555581bd42 in internal_condition_case (bfun=0x55555573a555 <command_loop_1>, handlers=..., hfun=0x5555557399ad <cmd_error>) at eval.c:1446
#19 0x000055555573a13e in command_loop_2 (handlers=...) at keyboard.c:1133
#20 0x000055555581af5a in internal_catch (tag=..., func=0x55555573a117 <command_loop_2>, arg=...) at eval.c:1181
#21 0x000055555573a0e3 in command_loop () at keyboard.c:1111
#22 0x000055555573947a in recursive_edit_1 () at keyboard.c:720
#23 0x000055555573968d in Frecursive_edit () at keyboard.c:803
#24 0x000055555573533e in main (argc=3, argv=0x7fffffffdf18) at emacs.c:2361
(gdb) show args
Argument list to give program being debugged when it is started is "--fg-daemon=lsp_server++ --no-init-file".
(gdb) xbacktrace 
Undefined command: "xbacktrace".  Try "help".
(gdb) source src/.gdbinit 
Warning: /media/local_17/src/emacs/git/emacs/../lwlib: No such file or directory.
DISPLAY = :0.0
TERM = xterm-256color
Breakpoint 1 at 0x5555557321c8: file emacs.c, line 399.
Breakpoint 2 at 0x5555556fd081: file xterm.c, line 10285.
(gdb) xbacktrace 
"command-error-default-function" (0xffffd428)
"apply" (0xffffd5f8)
0xea320740 PVEC_COMPILED


I am leaving my gdb emacs session alive just in case you might have
conjured up something new for me to check.

Cheers,

Andrei

PS. Sorry Lars I did not see your question on 02 Jun 2022. The answer
would have been I still suffer w/o a clear way to reproduce.
The latest time I was be invoking C-y or M-y.

> [Please use Reply All to reply, to keep the bug address CC'ed.]
>
>> From: andrei.elkin@pp.inet.fi
>> Date: Fri, 29 Oct 2021 20:19:40 +0300
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: andrei.elkin@pp.inet.fi
>> >> Cc: 48252@debbugs.gnu.org
>> >> Date: Fri, 29 Oct 2021 18:08:03 +0300
>> >> 
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> 
>> >> >> From: andrei.elkin@pp.inet.fi
>> >> >> Date: Thu, 28 Oct 2021 16:38:00 +0300
>> >> >> 
>> >> >> ...and what maybe is better that the most recent stack, below, is much shorter.
>> >> >> And I am leaving it alive in case there will be interest or just further
>> >> >> instruction for me.
>> >> >
>> >> > Please invoke xbacktrace and post the results.  (If GDB says it
>> >> > doesn't know that command, say "source /path/to/emacs/src/.gdbinit"
>> >> > first.)
>> >> 
>> >> (gdb) xbacktrace 
>> >> "command-error-default-function" (0xffffd448)
>> >> "apply" (0xffffd618)
>> >> 0xea3950a0 PVEC_COMPILED
>> >
>> > Is that all?  It should be a lot longer.
>> 
>> That's all though bt still produces the same stack.
>
> I've re-read the discussion till now, and I'm afraid this crash
> provides no new information that can allow us to make progress.  Once
> again, Emacs tries to signal an error, and the error data includes
> some invalid object.
>
> As I said earlier, the only way forward is to come up with a
> reproducible recipe starting from "emacs -Q", so that I or someone
> else could debug it locally.
>
> Or maybe you could figure out which Lisp code is running when this
> happens, and show the problematic Lisp.
>
> Sorry I couldn't be of more help.

bug#48252: Crashes continue ...

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hello again!

I have a question below.

Meanwhile ...
the stack persistently comes back for me, and yesterday in the
up-to-date emacs-28 branch (version 28.2.50).

It takes some days, maybe weeks until I start feeling some slowness
in responses to commands.
I must have learned that the stack appears in correlation with
C-k or just delete-char commands.

I previously thought it might have something to do with `lsp`. Can't yet
dismiss that feeling.

What if I skip (comment out)
  #1 print_object
if I know somehow that  SYMBOL_NAME() will segfault?
If that would deter emacs from crashing even for few more weeks :-), I'd
be happier than I am now.

Cheers,

Andrei

bug#48252: Crashes continue ...

[Eli Zaretskii]

> Date: Wed, 21 Dec 2022 15:18:39 +0200
> From: andrei.elkin--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Hello again!
> 
> I have a question below.
> 
> Meanwhile ...
> the stack persistently comes back for me, and yesterday in the
> up-to-date emacs-28 branch (version 28.2.50).

And in Emacs 29 what happens?

> It takes some days, maybe weeks until I start feeling some slowness
> in responses to commands.
> I must have learned that the stack appears in correlation with
> C-k or just delete-char commands.
> 
> I previously thought it might have something to do with `lsp`. Can't yet
> dismiss that feeling.
> 
> What if I skip (comment out)
>   #1 print_object
> if I know somehow that  SYMBOL_NAME() will segfault?
> If that would deter emacs from crashing even for few more weeks :-), I'd
> be happier than I am now.

I'm sorry, but the only way forward is either to have a reproducible
recipe of sorts.  We must understand how this invalid object comes to
life.

The segfault happens when Emacs tries to dereference an invalid
pointer.  If someone knows how to detect that, please speak up.

bug#48252: Crashes continue ...

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 21 Dec 2022 15:18:39 +0200
>> From: andrei.elkin--- via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> Hello again!
>> 
>> I have a question below.
>> 
>> Meanwhile ...
>> the stack persistently comes back for me, and yesterday in the
>> up-to-date emacs-28 branch (version 28.2.50).
>
> And in Emacs 29 what happens?

I'll relocate to it after any next crash.

>
>> It takes some days, maybe weeks until I start feeling some slowness
>> in responses to commands.
>> I must have learned that the stack appears in correlation with
>> C-k or just delete-char commands.
>> 
>> I previously thought it might have something to do with `lsp`. Can't yet
>> dismiss that feeling.
>> 
>> What if I skip (comment out)
>>   #1 print_object
>> if I know somehow that  SYMBOL_NAME() will segfault?
>> If that would deter emacs from crashing even for few more weeks :-), I'd
>> be happier than I am now.
>
> I'm sorry, but the only way forward is either to have a reproducible
> recipe of sorts.  We must understand how this invalid object comes to
> life.
>
> The segfault happens when Emacs tries to dereference an invalid
> pointer.  If someone knows how to detect that, please speak up.

My hope obviously has been that an invalid object gets exposed so far
in my case only via that stack, and might be harmless otherwise.

bug#48252: Possible Emacs 29 version of bug=48252

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Howdy Eli and comrades.

> And in Emacs 29 what happens?

After I switch to `git branch => emacs-29` I got two stacks
within two-three days.
The last one is on 86b03046c00 (HEAD -> emacs-29, origin/emacs-29)

#0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:426
#1  0x00005555557ace61 in emacs_abort () at sysdep.c:2313
#2  0x0000555555829dbf in process_mark_stack (base_sp=0) at alloc.c:7015
#3  0x000055555582a0c2 in mark_object (obj=XIL(0x55556144e0e3)) at alloc.c:7061
#4  0x000055555579ad24 in mark_kboards () at keyboard.c:13310
#5  0x0000555555827f78 in garbage_collect () at alloc.c:6204
#6  0x0000555555827bc0 in maybe_garbage_collect () at alloc.c:6107
#7  0x00005555558ce2a9 in maybe_gc () at lisp.h:5588
#8  0x00005555558cf4fc in exec_byte_code (fun=XIL(0x7fffe9c781bd), args_template=1026, nargs=3, args=0x7fffe910f070) at bytecode.c:782
#9  0x000055555586bb6d in fetch_and_exec_byte_code (fun=XIL(0x7fffe9da26e5), args_template=771, nargs=3, args=0x7fffffffd228) at eval.c:3081
#10 0x000055555586bffc in funcall_lambda (fun=XIL(0x7fffe9da26e5), nargs=3, arg_vector=0x7fffffffd228) at eval.c:3153
#11 0x000055555586b23d in funcall_general (fun=XIL(0x7fffe9da26e5), numargs=3, args=0x7fffffffd228) at eval.c:2945
#12 0x000055555586b53f in Ffuncall (nargs=4, args=0x7fffffffd220) at eval.c:2995
#13 0x0000555555755240 in call3 (fn=XIL(0x2aaa93b0b950), arg1=XIL(0x150), arg2=XIL(0x2aaa938174c0), arg3=XIL(0x5555608e03d4)) at lisp.h:3261
#14 0x0000555555756ac1 in x_get_local_selection (selection_symbol=XIL(0x150), target_type=XIL(0x2aaa938174c0), local_request=false, dpyinfo=0x5555567dcca0, local_value=XIL(0), need_alternate=false) at xselect.c:392
#15 0x00005555557582cd in x_convert_selection (selection_symbol=XIL(0x150), target_symbol=XIL(0x2aaa938174c0), property=460, for_multiple=false, dpyinfo=0x5555567dcca0, use_alternate=false) at xselect.c:983
#16 0x000055555575814d in x_handle_selection_request (event=0x7fffffffd4b0) at xselect.c:937
#17 0x0000555555758981 in x_handle_selection_event (event=0x7fffffffd4b0) at xselect.c:1091
#18 0x00005555557840b7 in process_special_events () at keyboard.c:4437
#19 0x0000555555784105 in swallow_events (do_display=false) at keyboard.c:4479
#20 0x000055555577e396 in read_char (commandflag=1, map=XIL(0x55555c3f71c3), prev_event=XIL(0), used_mouse_menu=0x7fffffffd8ad, end_time=0x0) at keyboard.c:2616
#21 0x0000555555793e82 in read_key_sequence (keybuf=0x7fffffffdaa0, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:10073
#22 0x0000555555779f2e in command_loop_1 () at keyboard.c:1375
#23 0x00005555558668de in internal_condition_case (bfun=0x555555779ae9 <command_loop_1>, handlers=XIL(0x90), hfun=0x555555778f23 <cmd_error>) at eval.c:1474
#24 0x00005555557796d2 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1124
#25 0x0000555555865a8e in internal_catch (tag=XIL(0xffc0), func=0x5555557796ab <command_loop_2>, arg=XIL(0x90)) at eval.c:1197
#26 0x0000555555779667 in command_loop () at keyboard.c:1102
#27 0x00005555557789e6 in recursive_edit_1 () at keyboard.c:711
#28 0x0000555555778c03 in Frecursive_edit () at keyboard.c:794
#29 0x00005555557741a0 in main (argc=1, argv=0x7fffffffdf28) at emacs.c:2529

Lisp Backtrace:
"Automatic GC" (0x0)
"string-replace" (0xe910f0b8)
"xselect--encode-string" (0xe910f058)
"xselect-convert-to-string" (0xffffd228)

I am keeping the gdb session for a while with a hope you would like
to search for something which I would be glad immediately serving as a remote
handle :-).

Cheers,

Andrei

bug#48252: Follow-up: Possible Emacs 29 version of bug=48252

[andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> And in Emacs 29 what happens?

>After I switch to `git branch => emacs-29` I got two stacks
>within two-three days.

Actually could this stack relate to the fact that I did not recompile
packages left from the previous emacs-28 realm?

There was not something (M-x magit-log specifically errored out) not
properly working in magit (though most of it was fine).



The last one is on 86b03046c00 (HEAD -> emacs-29, origin/emacs-29)

#0  terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:426
#1  0x00005555557ace61 in emacs_abort () at sysdep.c:2313
#2  0x0000555555829dbf in process_mark_stack (base_sp=0) at alloc.c:7015
#3  0x000055555582a0c2 in mark_object (obj=XIL(0x55556144e0e3)) at alloc.c:7061
#4  0x000055555579ad24 in mark_kboards () at keyboard.c:13310
#5  0x0000555555827f78 in garbage_collect () at alloc.c:6204
#...

bug#48252: Possible Emacs 29 version of bug=48252

[Eli Zaretskii]

> Date: Thu, 02 Feb 2023 14:17:36 +0200
> From: andrei.elkin--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Lisp Backtrace:
> "Automatic GC" (0x0)
> "string-replace" (0xe910f0b8)
> "xselect--encode-string" (0xe910f058)
> "xselect-convert-to-string" (0xffffd228)
> 
> I am keeping the gdb session for a while with a hope you would like
> to search for something which I would be glad immediately serving as a remote
> handle :-).

Thanks, I don't have any ideas.  Maybe Po Lu will?

bug#48252: Follow-up: Possible Emacs 29 version of bug=48252

[Eli Zaretskii]

> Date: Thu, 02 Feb 2023 15:38:15 +0200
> From: andrei.elkin--- via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> >> And in Emacs 29 what happens?
> 
> >After I switch to `git branch => emacs-29` I got two stacks
> >within two-three days.
> 
> Actually could this stack relate to the fact that I did not recompile
> packages left from the previous emacs-28 realm?

That should not cause crashes.

> There was not something (M-x magit-log specifically errored out) not
> properly working in magit (though most of it was fine).

This could be because you didn't recompile Magit.