bug#48252: Crashes continue ...

[andrei . elkin]

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.