From: Eli Zaretskii <eliz@gnu.org>
To: Jake Goulding <jake.goulding@gmail.com>
Cc: 30320@debbugs.gnu.org
Subject: bug#30320: 26.0.91; Crash when using lsp-ui-doc-mode
Date: Sun, 04 Feb 2018 20:35:34 +0200 [thread overview]
Message-ID: <83y3k88ux5.fsf@gnu.org> (raw)
In-Reply-To: <CAEDNNqCmBRq-F4QJJvAZD3un2AXdUBAykp0mWw+DPOu4=ZOxjg@mail.gmail.com> (message from Jake Goulding on Sat, 3 Feb 2018 16:55:16 -0500)
> From: Jake Goulding <jake.goulding@gmail.com>
> Date: Sat, 3 Feb 2018 16:55:16 -0500
> Cc: 30320@debbugs.gnu.org
>
> The frame size changes multiple times, including once to 3 before
> being set back to a larger value. Here are the stack traces of each
> breakpoint; the last one is right before the crash.
Here's the instance that shows the offending frame resizing (notice
the "new_height=3" part):
> * > Process 45031 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 1
> frame #0: 0x000000010001d2cc
> Emacs`adjust_frame_size(f=0x000000010393ba00, new_width=10,
> new_height=3, inhibit=1, pretend=false, parameter=43968) at
> frame.c:723
> 720 manipulating video hardware. */
> 721 if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
> 722 FrameRows (FRAME_TTY (f)) = new_lines + FRAME_TOP_MARGIN (f);
> -> 723 }
> 724 else if (new_lines != old_lines)
> 725 call2 (Qwindow__pixel_to_total, frame, Qnil);
> 726
> Target 0: (Emacs) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = watchpoint 1
> * frame #0: 0x000000010001d2cc
> Emacs`adjust_frame_size(f=0x000000010393ba00, new_width=10,
> new_height=3, inhibit=1, pretend=false, parameter=43968) at
> frame.c:723
> frame #1: 0x0000000100033e56
> Emacs`Fset_frame_size(frame=4354980357, width=42, height=14,
> pixelwise=45936) at frame.c:3458
> frame #2: 0x00000001002e57a9
> Emacs`funcall_subr(subr=0x00000001004d3880, numargs=4,
> args=0x00007ffeefbf7dd8) at eval.c:2849
> frame #3: 0x00000001002e40bd Emacs`Ffuncall(nargs=5,
> args=0x00007ffeefbf7dd0) at eval.c:2766
> frame #4: 0x000000010037a3fb
> Emacs`exec_byte_code(bytestr=4316213668, vector=4321330677,
> maxdepth=82, args_template=1030, nargs=1, args=0x00007ffeefbf8938) at
> bytecode.c:629
> frame #5: 0x00000001002e5cd5 Emacs`funcall_lambda(fun=4321330885,
> nargs=1, arg_vector=0x00007ffeefbf8930) at eval.c:2967
> frame #6: 0x00000001002e4105 Emacs`Ffuncall(nargs=2,
> args=0x00007ffeefbf8928) at eval.c:2768
> frame #7: 0x000000010037a3fb
> Emacs`exec_byte_code(bytestr=4316214228, vector=4321342069,
> maxdepth=26, args_template=2058, nargs=2, args=0x00007ffeefbf9440) at
> bytecode.c:629
> frame #8: 0x00000001002e5cd5 Emacs`funcall_lambda(fun=4321342181,
> nargs=2, arg_vector=0x00007ffeefbf9430) at eval.c:2967
> frame #9: 0x00000001002e4105 Emacs`Ffuncall(nargs=3,
> args=0x00007ffeefbf9428) at eval.c:2768
> frame #10: 0x000000010037a3fb
> Emacs`exec_byte_code(bytestr=4316213188, vector=4321329173,
> maxdepth=34, args_template=3086, nargs=3, args=0x00007ffeefbf9f20) at
> bytecode.c:629
> frame #11: 0x00000001002e5cd5 Emacs`funcall_lambda(fun=4321329269,
> nargs=3, arg_vector=0x00007ffeefbf9f08) at eval.c:2967
> frame #12: 0x00000001002e4105 Emacs`Ffuncall(nargs=4,
> args=0x00007ffeefbf9f00) at eval.c:2768
> frame #13: 0x000000010037a3fb
> Emacs`exec_byte_code(bytestr=4316213060, vector=4354401397,
> maxdepth=22, args_template=1030, nargs=1, args=0x00007ffeefbfa9f0) at
> bytecode.c:629
> frame #14: 0x00000001002e5cd5 Emacs`funcall_lambda(fun=4355101269,
> nargs=1, arg_vector=0x00007ffeefbfa9e8) at eval.c:2967
> frame #15: 0x00000001002e4105 Emacs`Ffuncall(nargs=2,
> args=0x00007ffeefbfa9e0) at eval.c:2768
> frame #16: 0x000000010037a3fb
> Emacs`exec_byte_code(bytestr=4317253604, vector=4329055989,
> maxdepth=58, args_template=2058, nargs=2, args=0x00007ffeefbfb628) at
> bytecode.c:629
> frame #17: 0x00000001002e5cd5 Emacs`funcall_lambda(fun=4329056293,
> nargs=2, arg_vector=0x00007ffeefbfb618) at eval.c:2967
> frame #18: 0x00000001002e4105 Emacs`Ffuncall(nargs=3,
> args=0x00007ffeefbfb610) at eval.c:2768
> frame #19: 0x000000010037a3fb
> Emacs`exec_byte_code(bytestr=4317253988, vector=4345900853,
> maxdepth=38, args_template=2058, nargs=2, args=0x00007ffeefbfc158) at
> bytecode.c:629
> frame #20: 0x00000001002e5cd5 Emacs`funcall_lambda(fun=4345901061,
> nargs=2, arg_vector=0x00007ffeefbfc148) at eval.c:2967
> frame #21: 0x00000001002e4105 Emacs`Ffuncall(nargs=3,
> args=0x00007ffeefbfc140) at eval.c:2768
> frame #22: 0x00000001002e3e3a Emacs`Fapply(nargs=2,
> args=0x00007ffeefbfc958) at eval.c:2386
> frame #23: 0x00000001002c68b5 Emacs`apply1(fn=4345901061,
> arg=4354286451) at eval.c:2602
> frame #24: 0x000000010039bc20
> Emacs`read_process_output_call(fun_and_args=4354286419) at
> process.c:5794
> frame #25: 0x00000001002d4e6a
> Emacs`internal_condition_case_1(bfun=(Emacs`read_process_output_call
> at process.c:5793), arg=4354286419, handlers=18672,
> hfun=(Emacs`read_process_output_error_handler at process.c:5799)) at
> eval.c:1356
> frame #26: 0x000000010039bb19
> Emacs`read_and_dispose_of_process_output(p=0x0000000103093230,
> chars="Content-Length:
> 117\r\n\r\n{\"jsonrpc\":\"2.0\",\"id\":19,\"result\":{\"contents\":[\"
> Wowzers\\n\",{\"language\":\"rust\",\"value\":\"fn () ->
> ()\"}],\"range\":null}}\x01", nbytes=140, coding=0x00000001029429c0)
> at process.c:6002
> frame #27: 0x0000000100395b3c
> Emacs`read_process_output(proc=4345901621, channel=12) at
> process.c:5913
This looks like a process filter set up by one of the features
involved in this. It seems to resize the frame, most probably on the
assumption that it's a GUI frame, because resizing a TTY frame, which
is your case, makes no sense.
Can you figure out the Lisp backtrace corresponding to the above C
backtrace? The file src/.gdbinit defines a command "xbacktrace",
which does that, but I'm not sure if lldb can support user-defined
commands like GDB does. If it can, just tell lldb to read that file,
and then invoke xbacktrace when Emacs stops due to watchpoint that
shows the frame being resized to height of 3.
If lldb doesn't support user-defined commands, you can reconstruct the
Lisp backtrace by following the frames that call Ffuncall: the first
element of the args[] array passed to Ffuncall is the symbol of the
function that is being called. To display the name of that symbol,
you will have to emulate by hand what the xsymbol command, defined on
.gdbinit, does.
We should anyway protect TTY frames from causing a crash when resized
to such nonsensical sizes, but I'd like first to see the Lisp which
causes that.
Thanks.
next prev parent reply other threads:[~2018-02-04 18:35 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-01 15:10 bug#30320: 26.0.91; Crash when using lsp-ui-doc-mode Jake Goulding
2018-02-01 17:16 ` Eli Zaretskii
2018-02-01 19:52 ` Jake Goulding
2018-02-01 19:54 ` Jake Goulding
2018-02-02 8:21 ` Eli Zaretskii
2018-02-02 16:22 ` Jake Goulding
2018-02-03 9:04 ` martin rudalics
2018-02-03 16:10 ` Jake Goulding
2018-02-03 16:34 ` Eli Zaretskii
2018-02-03 19:43 ` Jake Goulding
2018-02-03 20:10 ` Eli Zaretskii
2018-02-03 21:55 ` Jake Goulding
2018-02-04 18:35 ` Eli Zaretskii [this message]
2018-02-04 21:08 ` Jake Goulding
2018-02-04 21:38 ` Jake Goulding
2018-02-05 17:03 ` Eli Zaretskii
2018-02-05 18:43 ` Jake Goulding
2018-02-05 20:14 ` Eli Zaretskii
2018-02-06 9:29 ` martin rudalics
2018-02-10 10:14 ` Eli Zaretskii
2018-02-10 10:45 ` martin rudalics
2018-02-10 12:11 ` Eli Zaretskii
2018-02-10 13:40 ` martin rudalics
2018-02-10 16:38 ` Eli Zaretskii
2018-02-11 9:36 ` martin rudalics
2018-02-11 15:43 ` Eli Zaretskii
2018-02-12 1:31 ` Jake Goulding
2018-02-12 1:33 ` Jake Goulding
2018-02-12 1:48 ` Jake Goulding
2018-02-12 9:24 ` martin rudalics
2019-10-30 11:06 ` Lars Ingebrigtsen
2018-02-12 9:22 ` martin rudalics
2018-02-12 9:22 ` martin rudalics
2018-02-12 9:22 ` martin rudalics
2018-02-12 18:04 ` Eli Zaretskii
2018-02-10 19:04 ` Jake Goulding
2018-02-02 8:27 ` martin rudalics
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83y3k88ux5.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=30320@debbugs.gnu.org \
--cc=jake.goulding@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.