Open hyperreal64 opened 1 month ago
UPDATE: I was using Emacs version 29.4 from the Fedora package repositories.
I've compiled version 28.2 from source and so far there aren't any segfaults when using LSP.
Can you also reproduce the bug in Emacs 29.4 without using doom emacs but just using plain lsp-mode ?
I have the same issue. I tried both vanilla emacs 29.4 and emacs-wayland.
This is my stacktrace:
Fatal error 11: Segmentation fault
Backtrace:
emacs(+0x13d374) [0x557b7b228374]
emacs(+0x1fcd0) [0x557b7b10acd0]
emacs(+0x20e52) [0x557b7b10be52]
emacs(+0x29f03d) [0x557b7b38a03d]
/usr/lib/libc.so.6(+0x3c5b0) [0x557b76ac05b0]
emacs(+0x1c61a8) [0x557b7b2b11a8]
emacs(+0x127eef) [0x557b7b212eef]
emacs(+0x1352c8) [0x557b7b2202c8]
emacs(+0x1242c7) [0x557b7b20f2c7]
emacs(+0x1e5f31) [0x557b7b2d0f31]
/usr/bin/../lib/emacs/29.4/native-lisp/29.4-a0810582/preloaded/subr-13adf6a6-bfb9f448.eln(F7369742d666f72_sit_for_0+0x1c7) [0x557b73560337]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
/root/.config/emacs/.local/cache/eln/29.4-a0810582/lsp-mode-6666b574-6ee62a7e.eln(F6c73702d726571756573742d7768696c652d6e6f2d696e707574_lsp_request_while_no_input_0+0x447) [0x557b6c163b57]
emacs(+0x20b4fe) [0x557b7b2f64fe]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
emacs(+0x15b5df) [0x557b7b2465df]
emacs(+0x20b4fe) [0x557b7b2f64fe]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
/usr/bin/../lib/emacs/29.4/native-lisp/29.4-a0810582/preloaded/minibuffer-1b0f548b-25462d74.eln(F636f6d706c6574696f6e2d2d736f6d65_completion__some_0+0x202) [0x557b725ba8f2]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
/usr/bin/../lib/emacs/29.4/native-lisp/29.4-a0810582/preloaded/minibuffer-1b0f548b-25462d74.eln(F636f6d706c6574696f6e2d2d6e74682d636f6d706c6574696f6e_completion__nth_completion_0+0x2e4) [0x557b725bff24]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
/usr/bin/../lib/emacs/29.4/native-lisp/29.4-a0810582/preloaded/minibuffer-1b0f548b-25462d74.eln(F636f6d706c6574696f6e2d616c6c2d636f6d706c6574696f6e73_completion_all_completions_0+0x5e) [0x557b725c033e]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
emacs(+0x1b8b20) [0x557b7b2a3b20]
emacs(+0x20b4fe) [0x557b7b2f64fe]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
/root/.config/emacs/.local/cache/eln/29.4-a0810582/company-capf-997787ee-0ccac283.eln(F636f6d70616e792d636170662d2d63616e646964617465732d31_company_capf__candidates_1_0+0x39d) [0x557b6d17a7fd]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
/root/.config/emacs/.local/cache/eln/29.4-a0810582/company-capf-997787ee-0ccac283.eln(F636f6d70616e792d636170662d2d63616e64696461746573_company_capf__candidates_0+0x1ad) [0x557b6d17a11d]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
emacs(+0x1b8e0a) [0x557b7b2a3e0a]
emacs(+0x1b9ea4) [0x557b7b2a4ea4]
emacs(+0x1baf4d) [0x557b7b2a5f4d]
emacs(+0x1b9c66) [0x557b7b2a4c66]
emacs(+0x1bbd4d) [0x557b7b2a6d4d]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
emacs(+0x1b8e0a) [0x557b7b2a3e0a]
emacs(+0x20b4fe) [0x557b7b2f64fe]
emacs(+0x1b7c6e) [0x557b7b2a2c6e]
/root/.config/emacs/.local/cache/eln/29.4-a0810582/company-capf-997787ee-0ccac283.eln(F636f6d70616e792d63617066_company_capf_0+0x23f) [0x557b6d178b4f]
...
fish: Job 1, 'emacs' terminated by signal SIGSEGV (Address boundary error)
Emacs 29.4 seems to run fine in plain LSP mode but I didn't test it for very long. I had a Python project opened with LSP mode enabled and was able to use it for a while until it crashed again. Here is the backtrace from said crash, which might give a clue as to the cause. It looks like company has something to do with it this time, same as for @luciusmagn. I do notice that the crash only happens when the code completion menu pops up. I'm going to try disabling company and using corfu.
Fatal error 11: Segmentation fault
Backtrace:
/usr/bin/emacs(emacs_backtrace+0x5a)[0x5982ea]
/usr/bin/emacs(terminate_due_to_signal+0x9f)[0x4678b5]
/usr/bin/emacs[0x468653]
/usr/bin/emacs[0x7116c4]
/lib64/libc.so.6(+0x40d00)[0x7fe18c84fd00]
/usr/bin/emacs(parse_modifiers+0x104)[0x57c2e4]
/usr/bin/emacs[0x5930c8]
/usr/bin/emacs(read_char+0x218a)[0x581b7a]
/usr/bin/emacs[0x64d282]
/usr/bin/../lib64/emacs/29.4/native-lisp/29.4-95d1479c/preloaded/subr-13adf6a6-bfb9f448.eln(F7369742d666f72_sit_for_0+0x19f)[0x7fe186b623af]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/home/jas/.config/emacs/.local/cache/eln/29.4-95d1479c/lsp-mode-4bd57f83-6ee62a7e.eln(F6c73702d726571756573742d7768696c652d6e6f2d696e707574_lsp_request_while_no_input_0+0x427)[0x7fe16d6108f7]
/usr/bin/emacs(exec_byte_code+0x56c)[0x6701bc]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/usr/bin/emacs(Fall_completions+0x372)[0x5b8c42]
/usr/bin/emacs(exec_byte_code+0x56c)[0x6701bc]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/usr/bin/../lib64/emacs/29.4/native-lisp/29.4-95d1479c/preloaded/minibuffer-1b0f548b-25462d74.eln(F636f6d706c6574696f6e2d2d736f6d65_completion__some_0+0x1e2)[0x7fe185ba9852]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/usr/bin/../lib64/emacs/29.4/native-lisp/29.4-95d1479c/preloaded/minibuffer-1b0f548b-25462d74.eln(F636f6d706c6574696f6e2d2d6e74682d636f6d706c6574696f6e_completion__nth_completion_0+0x2d4)[0x7fe185bae914]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/usr/bin/../lib64/emacs/29.4/native-lisp/29.4-95d1479c/preloaded/minibuffer-1b0f548b-25462d74.eln(F636f6d706c6574696f6e2d616c6c2d636f6d706c6574696f6e73_completion_all_completions_0+0x50)[0x7fe185baecd0]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/usr/bin/emacs(Fapply+0x1b0)[0x6255c0]
/usr/bin/emacs(exec_byte_code+0x56c)[0x6701bc]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/home/jas/.config/emacs/.local/cache/eln/29.4-95d1479c/company-capf-b4167445-0ccac283.eln(F636f6d70616e792d636170662d2d63616e646964617465732d31_company_capf__candidates_1_0+0x36d)[0x7fe16e61664d]
/usr/bin/emacs(exec_byte_code+0x56c)[0x6701bc]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/usr/bin/emacs(Fapply+0x4a2)[0x6258b2]
/usr/bin/emacs(eval_sub+0xa57)[0x61a797]
/usr/bin/emacs(Flet+0x2cd)[0x61b84d]
/usr/bin/emacs(eval_sub+0x839)[0x61a579]
/usr/bin/emacs[0x6249bd]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/usr/bin/emacs(Fapply+0x4a2)[0x6258b2]
/usr/bin/emacs(exec_byte_code+0x56c)[0x6701bc]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/home/jas/.config/emacs/.local/cache/eln/29.4-95d1479c/company-capf-b4167445-0ccac283.eln(F636f6d70616e792d63617066_company_capf_0+0x22f)[0x7fe16e614a5f]
/usr/bin/emacs(Ffuncall+0xfd)[0x624ead]
/home/jas/.config/emacs/.local/cache/eln/29.4-95d1479c/company-a57d1860-b64d4357.eln(F636f6d70616e792d2d6d756c74692d6261636b656e642d616461707465722d63616e64696461746573_company__multi_backend_adapter_candidates_0+0x9c)[0x7fe16f75091c]
...
[1] 183834 segmentation fault (core dumped) /usr/bin/emacs
I haven't had any issues using corfu so far. I'm going to try using LSP mode with lsp-start-plain
with company enabled for a while and see how it goes.
Hi, I can confirm that switching to corfu prevents the segfault
Probably cross post on the company-mode
repo as well?
Corresponding Doom issue: https://github.com/doomemacs/doomemacs/issues/7915. Though that issue suggests the problem is specific to Emacs 29, on my system it is still present after switching to git master (944e45d)
AFAIK we don't actually know if this is a company-mode, lsp-mode, Doom Emacs, or upstream Emacs issue. Or, rather, it's an upstream issue (Elisp is generally not supposed to cause segfaults), but we don't know how it shows up in this specific situation.
TL;DR after doing the debug runs below:
lsp-request-while-no-input
, within sit-for
, and the C backtrace shows Emacs is trying to get the event-symbol-element-mask property of a symbolWith a debugger I was able to trigger a crash on master (944e45d, with native-comp) with this message:
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
0x000055555579a569 in Fget (symbol=<optimized out>, propname=XIL(0x7e00)) at ../../src/fns.c:2629
2629 return plist_get (XSYMBOL (symbol)->u.s.plist, propname);
The C backtrace:
The propname in the final line refers to the event-symbol-element-mask
symbol, as can also be seen by going to the files and lines that the backtrace points to.
Lisp backtrace from gdb:
So the crash, at least in my case, seems to be, for some reason, happening in lsp-request-while-no-input
.
Also, notably, this is triggered by completion-preview-mode (an Emacs 30 feature) and not by Company, suggesting that Company is not the problem here.
After going back to Emacs 29.4 I am still able to reproduce it under gdb. Though I wasn't able to trigger it in another attempt when I turned off optimizations (-O0 -g3). My guess is because this is a race condition that is harder to trigger when the performance is worse.
For the 29.4 crash, the error is
Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
Fget (symbol=<optimized out>, propname=XIL(0x6a20)) at ../../src/fns.c:2516
2516 DEFUN ("get", Fget, Sget, 2, 2, 0,
C backtrace:
Lisp backtrace:
So on Emacs 29.4 this is happening at the same place: in lsp-request-while-no-input
, in sit-for
.
Same thing with Spacemacs + intelephense(PHP) with emacs 29.4. It started to happen at some moment about few months ago - maybe when emacs itself updated, I don't know. When autocomplete popup should appear emacs hangs for few seconds and then crashes this way:
Fatal error 11: Segmentation fault
Backtrace:
emacs(+0x192c0b) [0x5c17eb35bc0b]
emacs(+0x2396f) [0x5c17eb1ec96f]
emacs(+0x2477a) [0x5c17eb1ed77a]
emacs(+0x2d91e5) [0x5c17eb4a21e5]
/usr/lib/libc.so.6(+0x3d1d0) [0x73d3a9e5c1d0]
emacs(+0x2275db) [0x5c17eb3f05db]
emacs(+0x17af41) [0x5c17eb343f41]
emacs(+0x18af78) [0x5c17eb353f78]
emacs(+0x18087b) [0x5c17eb34987b]
emacs(+0x245a92) [0x5c17eb40ea92]
emacs(+0x26432c) [0x5c17eb42d32c]
emacs(+0x21c3ed) [0x5c17eb3e53ed]
emacs(+0x1b4c82) [0x5c17eb37dc82]
emacs(+0x26432c) [0x5c17eb42d32c]
emacs(+0x21c3ed) [0x5c17eb3e53ed]
emacs(+0x21cd20) [0x5c17eb3e5d20]
emacs(+0x26432c) [0x5c17eb42d32c]
emacs(+0x21c3ed) [0x5c17eb3e53ed]
emacs(+0x2dc63e) [0x5c17eb4a563e]
emacs(+0x172b92) [0x5c17eb33bb92]
emacs(+0x219aec) [0x5c17eb3e2aec]
emacs(+0x2f096d) [0x5c17eb4b996d]
emacs(+0x175087) [0x5c17eb33e087]
emacs(+0x20acce) [0x5c17eb3d3cce]
emacs(+0x17240e) [0x5c17eb33b40e]
emacs(+0x20ac28) [0x5c17eb3d3c28]
emacs(+0x174b8b) [0x5c17eb33db8b]
emacs(+0x2f07ff) [0x5c17eb4b97ff]
emacs(+0x176ccd) [0x5c17eb33fccd]
emacs(+0x34d9d) [0x5c17eb1fdd9d]
/usr/lib/libc.so.6(+0x25e08) [0x73d3a9e44e08]
/usr/lib/libc.so.6(__libc_start_main+0x8c) [0x73d3a9e44ecc]
emacs(+0x362f5) [0x5c17eb1ff2f5]
fish: Job 1, 'emacs' terminated by signal SIGSEGV (Address boundary error)
It happens quite rarely actually. Most of time I'm just working without any issues. It took me some time to catch it (launching emacs from command line and working until it crashes).
When I open emacs again, open the same project and do the same things which I was doing when it crashed (autocompleting the same item) - it just does it without crashing. So it's related rather to specific moment than to specific project code state.
I'm not really sure but it seems to happen more often while working on a laptop in powersaving cpu profile while the A/C adapter is detached - so it may be some timeout related issue. But again: I'm really not sure about this thing, it's very hard to gather reliable statistics because as I mentioned above in my case the crashes are generally quite rare.
Unfortunately Gdb info does not seem useful to me.
You need to run gdb from the src directory of a local Emacs source code checkout (to load src/.gdbinit), and also probably build Emacs from the local checkout, to get a useful backtrace. etc/DEBUG has some useful info as well and is worth a read.
Hi! I have face a similar issue with vanilla Emacs 29.4 on Arch Linux. I am using corfu, not company-mode
, but I use company backends with cape-company-to-capf
. The crashes are also seemingly random, but fairly frequent (perhaps every one or two hours).
I have found two bug reports in the GNU mailing lists that could be possibly be related:
As a temporary workaround, I have downgraded Emacs to 29.3. Since then, no crash has happened.
I hope this information can help others.
This looks right, and this bug is fixed in emacs 30 which will be released soon.
I tried out the Emacs 30 pretest, which includes the patch, and haven't encountered the crash once in several hours. I think this issue is fixed now (and it seems to have turned out to solely be an upstream issue).
(The corresponding commit on upstream master is a967efdd.)
Thank you for the bug report
lsp-mode
related packages.M-x lsp-start-plain
Bug description
When using the Go or Python LSP, the LSP is initialized and after a few seconds it causes Emacs to crash. It seems to be related to this bug. I ran Emacs from the terminal and then reproduced the crash. The backtrace is in the screenshot below. I'm not sure how else to debug this, but I would be more than happy to provide any other information and/or help run tests on my end.
Steps to reproduce
On my machine, all I have to do is open a Python or Go project, let the LSP initialize, start typing code, and then it segfaults.
Expected behavior
Emacs doesn't segfault.
Which Language Server did you use?
lsp-python, lsp-go
OS
Linux
Error callstack
No response
Anything else?
No response