GNU bug report logs - #30320
26.0.91; Crash when using lsp-ui-doc-mode

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jake Goulding <jake.goulding <at> gmail.com>
Cc: 30320 <at> 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

> From: Jake Goulding <jake.goulding <at> gmail.com>
> Date: Sat, 3 Feb 2018 16:55:16 -0500
> Cc: 30320 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.