From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70495: 29.3.50; M-x lsp leads to assertion failed: pdl->kind == SPECPDL_BACKTRACE Date: Sun, 21 Apr 2024 13:52:30 +0300 Message-ID: <86v84b6l8x.fsf@gnu.org> References: <87zftnaw9a.fsf@quad> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14833"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70495@debbugs.gnu.org To: andrei.elkin@pp.inet.fi Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 21 12:53:15 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ryUos-0003fO-RQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 21 Apr 2024 12:53:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ryUoT-0003At-Qm; Sun, 21 Apr 2024 06:52:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ryUoR-0003Aa-5g for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2024 06:52:47 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ryUoQ-0005X7-QQ for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2024 06:52:46 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ryUof-0006Jv-RY for bug-gnu-emacs@gnu.org; Sun, 21 Apr 2024 06:53:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 21 Apr 2024 10:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70495 X-GNU-PR-Package: emacs Original-Received: via spool by 70495-submit@debbugs.gnu.org id=B70495.171369678024289 (code B ref 70495); Sun, 21 Apr 2024 10:53:01 +0000 Original-Received: (at 70495) by debbugs.gnu.org; 21 Apr 2024 10:53:00 +0000 Original-Received: from localhost ([127.0.0.1]:42312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ryUod-0006Jd-Ij for submit@debbugs.gnu.org; Sun, 21 Apr 2024 06:53:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37130) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ryUoa-0006IH-8u for 70495@debbugs.gnu.org; Sun, 21 Apr 2024 06:52:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ryUoE-0005Wl-Et; Sun, 21 Apr 2024 06:52:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dZmtsf/4sy4gcHSdeXpdH+EcxVp/4+lv+RGfS3s17/Y=; b=PGVbeVk96nQ5 G1cWtxg7//LLQZFCBftNUkP2J1Ir1fzUgUbRh0+sDsISC1SVgPwijtduYcsvuz6C0zYxoeFSZCA2T T44aScyDQJaT9th2S0kY/uGNVyzZnAzdeNjzHjoJaWsKF2w8ACWwOhEd/84G2lcu3zHt7v8vvL9TL Hy4U58Ugd2vjApeMdwQrpSJbUxBZ0O5+v9XZxg/2ezI/Fsd5Fr1sCMM4pemkZkUwGeGVHn8GeHOnQ VHoZ1hRN1l2gfFpTVpHdv8DJY8gldHcFS62VunDF8Boit55v9w+79d79tr1ANuuveU5F1YFUWeCEv Gqurw5ppAhv9Jw93XW/SOw==; In-Reply-To: <87zftnaw9a.fsf@quad> (bug-gnu-emacs@gnu.org) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:283766 Archived-At: > Date: Sun, 21 Apr 2024 12:41:05 +0300 > From: andrei.elkin--- via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > How to reproduce > ================ > > 0. Have lsp-mode and lsp-ui installed with up-to-now (21.4.2024 12.23.26 +0300) > versions > > lsp-mode-20240317.1845 > lsp-ui-20240421.24 > > 1 Open a c++ file (compile_commands.json is not needed) > 2. do a few lsp commands like M-. to end up with > > xdisp.c:23978: Emacs fatal error: assertion failed: it->method == GET_FROM_BUFFER || it->method == GET_FROM_DISPLAY_VECTOR || it->method == GET_FROM_STRING || it->method == GET_FROM_IMAGE > Fatal error 6: Aborted Sorry, I cannot afford installing lsp-mode and lsp-ui (which in this case will need to also install clang for the LSP server, right?), and I don't know how to use it anyway. So I need you to tell me what's in the buffer at that position when this happens: how does lsp-mode/lsp-ui set the line-prefix or wrap-prefix, etc. If you can come up with a Lisp recipe that doesn't need lsp-* to be installed and still reproduces the problem, this would be the best, as I could debug this on my machine. Alternatively, give me an ssh login on your machine and give instructions for reproducing the problem (hopefully, it can be reproduced in a -nw session, i.e. without GUI frames), so I could look around and see what went wrong. As the minimum meaningful data for now, please type these GDB commands and tell what they produce: (gdb) frame 11 (gdb) print it->method (gdb) print it->sp > #11 0x000055555559cd88 in push_prefix_prop (prop=Python Exception value has been optimized out: > , it=0x7fffffff6c60) at xdisp.c:23978 I don't understand the above call-stack frame: it lists the arguments of push_prefix_prop in reverse order. The source code is this: static bool push_prefix_prop (struct it *it, Lisp_Object prop) so it's first 'it', then 'prop', whereas the backtrace above shows them in reverse order. It could be the problem with your optimized build, so please see if the problem can be reproduced in an unoptimized build (with the -O0 compiler switch), and post the backtrace from that build if it also aborts. Also, start GDB from a directory other than the Emacs 'src' directory, because it looks like the Python commands in src/.gdbinit cause trouble to your installation of GDB. > Configured using: > 'configure --with-x-toolkit=gtk --with-json > --enable-checking=yes,glyphs --enable-check-lisp-object-type > 'CFLAGS=-ggdb3 -O3' LDFLAGS=-ggdb3 'CXXFLAGS=-ggdb3 -O3'' Building Emacs with -O3 optimization switch is not a good idea: depending on your GCC version, this could produce invalid code due to all kinds of aggressive optimizations by GCC. So I'd be interested to know whether this abort happens with -O0 and -O2 optimization switches instead. (And if you do need to use -O3 for some reason, why on earth are you also using --enable-checking=yes,glyphs --enable-check-lisp-object-type, which add all kinds of run-time checks to Emacs, and are intended to be used by the Emacs developers when debugging Emacs?) What version of GCC are you using to build Emacs, btw? Thanks.