From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30320: 26.0.91; Crash when using lsp-ui-doc-mode Date: Sun, 04 Feb 2018 20:35:34 +0200 Message-ID: <83y3k88ux5.fsf@gnu.org> References: <83po5oeil8.fsf@gnu.org> <83a7wrer8i.fsf@gnu.org> <5A757B30.9070402@gmx.at> <83y3ka9gmg.fsf@gnu.org> <83mv0pal74.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1517769264 15998 195.159.176.226 (4 Feb 2018 18:34:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Feb 2018 18:34:24 +0000 (UTC) Cc: 30320@debbugs.gnu.org To: Jake Goulding Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 04 19:34:19 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiP77-00034J-HA for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Feb 2018 19:34:05 +0100 Original-Received: from localhost ([::1]:52879 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiP98-0006uo-I3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Feb 2018 13:36:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37897) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiP91-0006tU-Bu for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2018 13:36:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eiP90-00016h-78 for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2018 13:36:03 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:49425) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eiP90-00016b-2n for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2018 13:36:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eiP8z-0006nq-SM for bug-gnu-emacs@gnu.org; Sun, 04 Feb 2018 13:36:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Feb 2018 18:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30320 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 30320-submit@debbugs.gnu.org id=B30320.151776935626139 (code B ref 30320); Sun, 04 Feb 2018 18:36:01 +0000 Original-Received: (at 30320) by debbugs.gnu.org; 4 Feb 2018 18:35:56 +0000 Original-Received: from localhost ([127.0.0.1]:57322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiP8t-0006nW-SB for submit@debbugs.gnu.org; Sun, 04 Feb 2018 13:35:56 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:46887) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eiP8s-0006nJ-GX for 30320@debbugs.gnu.org; Sun, 04 Feb 2018 13:35:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eiP8j-0000jQ-0Z for 30320@debbugs.gnu.org; Sun, 04 Feb 2018 13:35:48 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60689) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eiP8i-0000jI-Se; Sun, 04 Feb 2018 13:35:44 -0500 Original-Received: from [176.228.60.248] (port=3048 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eiP8i-0004Oq-8c; Sun, 04 Feb 2018 13:35:44 -0500 In-reply-to: (message from Jake Goulding on Sat, 3 Feb 2018 16:55:16 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:142897 Archived-At: > From: Jake Goulding > 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.