unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: 48252@debbugs.gnu.org
Cc: andrei.elkin@pp.inet.fi
Subject: bug#48252: 28.0.50; Emacs crashes while printing an error message
Date: Thu, 06 May 2021 12:23:37 +0300	[thread overview]
Message-ID: <83r1ikdxly.fsf@gnu.org> (raw)
In-Reply-To: <871ralmhw2.fsf@quad> (andrei.elkin@pp.inet.fi)

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





       reply	other threads:[~2021-05-06  9:23 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87pmyeekkq.fsf@quad>
     [not found] ` <837dkmhavj.fsf@gnu.org>
     [not found]   ` <87wnsma5aw.fsf@quad>
     [not found]     ` <83im46fq68.fsf@gnu.org>
     [not found]       ` <87y2cupcb6.fsf@quad>
     [not found]         ` <837dke49jq.fsf@gnu.org>
     [not found]           ` <87wnsdob3m.fsf@quad>
     [not found]             ` <83o8dp2wba.fsf@gnu.org>
     [not found]               ` <871ralmhw2.fsf@quad>
2021-05-06  9:23                 ` Eli Zaretskii [this message]
2021-05-06 15:01                   ` bug#48252: 28.0.50; Emacs crashes while printing an error message andrei.elkin
2021-10-28 13:38                   ` bug#48252: Crashes continue andrei.elkin
2021-10-28 15:53                     ` Eli Zaretskii
2021-10-29 15:08                       ` andrei.elkin
2021-10-29 15:55                         ` Eli Zaretskii
     [not found]                           ` <87cznn7npv.fsf@quad>
2021-10-29 19:25                             ` Eli Zaretskii
2021-10-29 19:31                             ` Eli Zaretskii
2021-10-30 11:07                               ` andrei.elkin
2021-10-30 12:04                                 ` Eli Zaretskii
2022-06-02 13:19                                 ` bug#48252: 28.0.50; Emacs crashes while printing an error message Lars Ingebrigtsen
2022-07-01 11:03                                   ` Lars Ingebrigtsen
2022-11-22 18:14                               ` bug#48252: Crashes continue andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-21 13:18                   ` andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-21 13:56                     ` Eli Zaretskii
2022-12-21 15:14                       ` andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-02 12:17                   ` bug#48252: Possible Emacs 29 version of bug=48252 andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-02 14:25                     ` Eli Zaretskii
2023-02-02 13:38                   ` bug#48252: Follow-up: " andrei.elkin--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-02 14:29                     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83r1ikdxly.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=48252@debbugs.gnu.org \
    --cc=andrei.elkin@pp.inet.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).