search

emacs-lsp / lsp-mode

Emacs client/library for the Language Server Protocol
https://emacs-lsp.github.io/lsp-mode
GNU General Public License v3.0
4.75k stars 872 forks source link

Emacs hangs with 100% cpu #1621

Open dignifiedquire opened 4 years ago

dignifiedquire commented 4 years ago

I am running with the latest version of lsp-mode and rust-analyzer as of writing this. Also emacs 28.0.50.

I regularly get into a state where emacs hangs with 100% cpu utilization and I am unable to do anything, not even get a stacktrace (though that might be my skills)

This is the only clue of an error I could see on the screen

LSP :: Sending to process failed with the following error: Process rust-analyzer not running

It reproduces regularly while coding, but unclear what triggers it.

yyoncho commented 4 years ago

With this description, it is hard to guess what is causing your issue. Have you tried M-x toggle-debug-on-quit and then C-g when it hangs?

dignifiedquire commented 4 years ago

@yyoncho I did :( and emacs kept hanging and ignored my keyboard input

dignifiedquire commented 4 years ago

This is my lsp config: https://gist.github.com/dignifiedquire/d6f06aaf197ad790f899d9a6092657d9

yyoncho commented 4 years ago

Have you checked the performance guide in lsp-mode's readme? You are missing few critical settings, e. g. gc-cons-threshold unless they are part of another file.

dignifiedquire commented 4 years ago

Thanks, I somehow missed that section, even though I thought I read all of the readme..Retrying with those settings, will report back.

dignifiedquire commented 4 years ago

Update: I added the following to my config: 

gc-cons-threshold 100000000
read-process-output-max (* 1024 1024)
lsp-idle-delay 0.500

Now emacs will still hang, but cpu is not at 100% anymore, more around 5-10% for a while. It still becomes entirely unresponsive regularly though.

yyoncho commented 4 years ago

Now emacs will still hang, but cpu is not at 100% anymore, more around 5-10% for a while. It still becomes entirely unresponsive regularly though.

Please provide the required info as described in: https://github.com/emacs-lsp/lsp-mode#reporting-performance-problems

king6cong commented 4 years ago

Same here, using rust-analyzer, and cpu usage keeps 100%

lsp-mode settings:

setq gc-cons-threshold 600000000)
(setq read-process-output-max (* 4096 1024))
(setq lsp-prefer-capf t)
(setq lsp-idle-delay 0.500)
(setq lsp-print-performance t)

Here’s the profiling report: emacs_profiling_report.txt

yyoncho commented 4 years ago

@king6cong the sum of all lsp-mode related time is 0. Are you able to reproduce that with lsp-start-plain.el?

dignifiedquire commented 4 years ago

I have not been able to get a profiling report, but I was able to attach lldb to the hanging emacs. Before attaching emacs was using 99% cpu. 

(lldb) process attach --pid 26119
Process 26119 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x0000000107cf02ab libgmp.10.dylib`__gmpz_mul_ui + 3
libgmp.10.dylib`__gmpz_mul_ui:
->  0x107cf02ab <+3>: pushq  %r14
    0x107cf02ad <+5>: pushq  %r13
    0x107cf02af <+7>: pushq  %r12
    0x107cf02b1 <+9>: pushq  %rbx

Executable module set to "/usr/local/bin/emacs".
Architecture set to: x86_64h-apple-macosx.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x0000000107cf02ab libgmp.10.dylib`__gmpz_mul_ui + 3
    frame #1: 0x00000001076acd46 emacs`lisp_to_timespec + 234
    frame #2: 0x00000001076ac856 emacs`list4_to_timespec + 67
    frame #3: 0x0000000107601167 emacs`timer_check + 359
    frame #4: 0x00000001076a1496 emacs`wait_reading_process_output + 1312
    frame #5: 0x00000001076a0f28 emacs`Faccept_process_output + 355
    frame #6: 0x00000001076677fe emacs`funcall_subr + 244
    frame #7: 0x00000001076670c3 emacs`Ffuncall + 639
    frame #8: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #9: 0x0000000107667061 emacs`Ffuncall + 541
    frame #10: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #11: 0x0000000107667061 emacs`Ffuncall + 541
    frame #12: 0x00000001076674fe emacs`call3 + 54
    frame #13: 0x00000001076677fe emacs`funcall_subr + 244
    frame #14: 0x00000001076670c3 emacs`Ffuncall + 639
    frame #15: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #16: 0x0000000107667061 emacs`Ffuncall + 541
    frame #17: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #18: 0x0000000107667061 emacs`Ffuncall + 541
    frame #19: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #20: 0x0000000107667061 emacs`Ffuncall + 541
    frame #21: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #22: 0x0000000107667061 emacs`Ffuncall + 541
    frame #23: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #24: 0x0000000107667061 emacs`Ffuncall + 541
    frame #25: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #26: 0x0000000107667061 emacs`Ffuncall + 541
    frame #27: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #28: 0x0000000107667061 emacs`Ffuncall + 541
    frame #29: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #30: 0x0000000107667061 emacs`Ffuncall + 541
    frame #31: 0x0000000107666cf3 emacs`Fapply + 577
    frame #32: 0x00000001076670c3 emacs`Ffuncall + 639
    frame #33: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #34: 0x0000000107667061 emacs`Ffuncall + 541
    frame #35: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #36: 0x0000000107667061 emacs`Ffuncall + 541
    frame #37: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #38: 0x0000000107667061 emacs`Ffuncall + 541
    frame #39: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #40: 0x0000000107667061 emacs`Ffuncall + 541
    frame #41: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #42: 0x0000000107667061 emacs`Ffuncall + 541
    frame #43: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #44: 0x0000000107667061 emacs`Ffuncall + 541
    frame #45: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #46: 0x0000000107667061 emacs`Ffuncall + 541
    frame #47: 0x0000000107666cf3 emacs`Fapply + 577
    frame #48: 0x00000001076670c3 emacs`Ffuncall + 639
    frame #49: 0x000000010769a000 emacs`exec_byte_code + 1370
    frame #50: 0x0000000107667061 emacs`Ffuncall + 541
    frame #51: 0x00000001076674ad emacs`call1 + 46
    frame #52: 0x0000000107601307 emacs`timer_check + 775
    frame #53: 0x000000010760009f emacs`readable_events + 21
    frame #54: 0x0000000107600fab emacs`get_input_pending + 48
    frame #55: 0x00000001075ffeba emacs`detect_input_pending_run_timers + 46
    frame #56: 0x00000001076a1edd emacs`wait_reading_process_output + 3943
    frame #57: 0x000000010757e981 emacs`sit_for + 309
    frame #58: 0x00000001075fe7f3 emacs`read_char + 4647
    frame #59: 0x00000001075fc1c5 emacs`read_key_sequence + 1481
    frame #60: 0x00000001075fadf7 emacs`command_loop_1 + 869
    frame #61: 0x0000000107665c82 emacs`internal_condition_case + 84
    frame #62: 0x0000000107607055 emacs`command_loop_2 + 37
    frame #63: 0x0000000107665926 emacs`internal_catch + 74
    frame #64: 0x00000001076cd40e emacs`command_loop.cold.1 + 69
    frame #65: 0x00000001075fa4b3 emacs`command_loop + 131
    frame #66: 0x00000001075fa3f0 emacs`recursive_edit_1 + 110
    frame #67: 0x00000001075fa5b0 emacs`Frecursive_edit + 226
    frame #68: 0x00000001075f9826 emacs`main + 5878
    frame #69: 0x00007fff78d403d5 libdyld.dylib`start + 1
jiacai2050 commented 4 years ago

Same here.

lldb output

(lldb) attach 78893
Emacs was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 78893 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x0000000106efeb3d Emacs`assq_no_quit [inlined] TAGGEDP(a=0x00007fd51e086bb3, tag=Lisp_Cons) at lisp.h:759:10 [opt]
   756  INLINE bool
   757  (TAGGEDP) (Lisp_Object a, enum Lisp_Type tag)
   758  {
-> 759    return lisp_h_TAGGEDP (a, tag);
   760  }
   761
   762  INLINE void
Target 0: (Emacs) stopped.

Executable module set to "/Applications/Emacs.app/Contents/MacOS/Emacs".
Architecture set to: x86_64h-apple-macosx-.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x0000000106efeb30 Emacs`assq_no_quit [inlined] XCDR(c=<unavailable>) at lisp.h:1450:10 [opt]
    frame #1: 0x0000000106efeb2b Emacs`assq_no_quit(key=0x00000000015fade8, list=0x00007fd51e06aa23) at fns.c:1626 [opt]
    frame #2: 0x0000000106e647c3 Emacs`get_lface_attributes [inlined] lface_from_face_name_no_resolve(f=<unavailable>, face_name=<unavailable>) at xfaces.c:0 [opt]
    frame #3: 0x0000000106e647a5 Emacs`get_lface_attributes [inlined] get_lface_attributes_no_remap(f=<unavailable>, face_name=<unavailable>, attrs=0x00007ffee8e49e60) at xfaces.c:1888 [opt]
    frame #4: 0x0000000106e647a5 Emacs`get_lface_attributes(w=<unavailable>, f=0x00007fd519ba7c30, face_name=0x00000000015fade8, attrs=0x00007ffee8e49e60, signal_p=<unavailable>, named_merge_points=<unavailable>) at xfaces.c:1939 [opt]
    frame #5: 0x0000000106e689c2 Emacs`merge_named_face(w=0x00007fd5196f8830, f=0x00007fd519ba7c30, face_name=<unavailable>, to=0x00007ffee8e4a450, named_merge_points=0x00000000015fade8, attr_filter=0) at xfaces.c:2217:17 [opt]
    frame #6: 0x0000000106e65390 Emacs`merge_face_ref(w=<unavailable>, f=0x00007fd519ba7c30, face_ref=0x00000000015fade8, to=0x00007ffee8e4a450, err_msgs=<unavailable>, named_merge_points=0x00007ffee8e4a1c8, attr_filter=0) at xfaces.c:2699:12 [opt]
    frame #7: 0x0000000106e65b4c Emacs`merge_face_ref(w=<unavailable>, f=0x00007fd519ba7c30, face_ref=<unavailable>, to=0x00007ffee8e4a450, err_msgs=<unavailable>, named_merge_points=0x00007ffee8e4a1c8, attr_filter=0) at xfaces.c:2691:10 [opt]
    frame #8: 0x0000000106e628ae Emacs`merge_face_vectors(w=<unavailable>, f=<unavailable>, from=0x00007ffee8e4a1e0, to=0x00007ffee8e4a450, named_merge_points=<unavailable>) at xfaces.c:2088:5 [opt]
    frame #9: 0x0000000106e68a3b Emacs`merge_named_face(w=0x00007fd5196f8830, f=0x00007fd519ba7c30, face_name=<unavailable>, to=0x00007ffee8e4a450, named_merge_points=0x0000000000008190, attr_filter=0) at xfaces.c:2229:9 [opt]
    frame #10: 0x0000000106e65390 Emacs`merge_face_ref(w=<unavailable>, f=0x00007fd519ba7c30, face_ref=0x0000000000008190, to=0x00007ffee8e4a450, err_msgs=<unavailable>, named_merge_points=0x00007ffee8e4a428, attr_filter=0) at xfaces.c:2699:12 [opt]
    frame #11: 0x0000000106e628ae Emacs`merge_face_vectors(w=<unavailable>, f=<unavailable>, from=0x00007ffee8e4a4f0, to=0x00007ffee8e4a450, named_merge_points=<unavailable>) at xfaces.c:2088:5 [opt]
    frame #12: 0x0000000106e68715 Emacs`merge_faces(w=0x00007fd5196f8830, face_name=0x00000000000081c0, face_id=0, base_face_id=0) at xfaces.c:0 [opt]
    frame #13: 0x0000000106df80be Emacs`maybe_produce_line_number(it=0x00007ffee8e4e100) at xdisp.c:22668:7 [opt]
    frame #14: 0x0000000106dd72d7 Emacs`display_line(it=0x00007ffee8e4e100, cursor_vpos=<unavailable>) at xdisp.c:23041:2 [opt]
    frame #15: 0x0000000106dd6d59 Emacs`try_window(window=0x00007fd5196f8835, pos=<unavailable>, flags=1) at xdisp.c:19062:11 [opt]
    frame #16: 0x0000000106e00288 Emacs`redisplay_window(window=0x00007fd5196f8835, just_this_one_p=<unavailable>) at xdisp.c:18480:8 [opt]
    frame #17: 0x0000000106dfe276 Emacs`redisplay_window_0(window=<unavailable>) at xdisp.c:16194:5 [opt]
    frame #18: 0x0000000106ef43ff Emacs`internal_condition_case_1(bfun=<unavailable>, arg=0x00007fd5196f8835, handlers=0x0000000108e6952b, hfun=(Emacs`redisplay_window_error at xdisp.c:16185)) at eval.c:1379:25 [opt]
    frame #19: 0x0000000106dfd94c Emacs`redisplay_windows(window=0x00007fd5196f8835) at xdisp.c:16174:4 [opt]
    frame #20: 0x0000000106dfd926 Emacs`redisplay_windows(window=0x00007fd519e181e5) at xdisp.c:16168:2 [opt]
    frame #21: 0x0000000106dd3fb6 Emacs`redisplay_internal at xdisp.c:15642:5 [opt]
    frame #22: 0x0000000106dd6026 Emacs`redisplay_preserve_echo_area(from_where=<unavailable>) at xdisp.c:15991:7 [opt]
    frame #23: 0x0000000106f41948 Emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=-1, do_display=<unavailable>, wait_for_cell=<unavailable>, wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5349:3 [opt]
    frame #24: 0x0000000106db2548 Emacs`sit_for(timeout=<unavailable>, reading=<unavailable>, display_option=1) at dispnew.c:6056:3 [opt]
    frame #25: 0x0000000106e71e8a Emacs`read_char(commandflag=1, map=0x00007fd519eab183, prev_event=0x0000000000000000, used_mouse_menu=0x00007ffee8e54e4b, end_time=0x0000000000000000) at keyboard.c:2738:11 [opt]
    frame #26: 0x0000000106e6ee9a Emacs`read_key_sequence(keybuf=<unavailable>, prompt=0x0000000000000000, dont_downcase_last=<unavailable>, can_return_switch_frame=<unavailable>, fix_current_buffer=<unavailable>, prevent_redisplay=<unavailable>) at keyboard.c:9553:12 [opt]
    frame #27: 0x0000000106e6d69c Emacs`command_loop_1 at keyboard.c:1350:15 [opt]
    frame #28: 0x0000000106ef42c7 Emacs`internal_condition_case(bfun=(Emacs`command_loop_1 at keyboard.c:1236), handlers=0x0000000000000090, hfun=(Emacs`cmd_error at keyboard.c:919)) at eval.c:1355:25 [opt]
    frame #29: 0x0000000106e7d820 Emacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1091:11 [opt]
    frame #30: 0x0000000106ef3adb Emacs`internal_catch(tag=0x000000000000c450, func=(Emacs`command_loop_2 at keyboard.c:1087), arg=0x0000000000000000) at eval.c:1116:25 [opt]
    frame #31: 0x0000000106fb20d5 Emacs`command_loop.cold.1 + 69
    frame #32: 0x0000000106e6c763 Emacs`command_loop at keyboard.c:1069:2 [opt]
    frame #33: 0x0000000106e6c693 Emacs`recursive_edit_1 at keyboard.c:714:9 [opt]
    frame #34: 0x0000000106e6c8eb Emacs`Frecursive_edit at keyboard.c:786:3 [opt]
    frame #35: 0x0000000106e6b4cc Emacs`main(argc=<unavailable>, argv=0x00007ffee8e552e8) at emacs.c:2054:3 [opt]
    frame #36: 0x00007fff640737fd libdyld.dylib`start + 1
    frame #37: 0x00007fff640737fd libdyld.dylib`start + 1
jiacai2050 commented 4 years ago

@yyoncho Do you have any suggestions how to debug this? Once Emacs goes to 100% CPU , I can type nothing.

kiennq commented 4 years ago

Seems like emacs problem to me. You should probably report-emacs-bug too. @Eli-Zaretskii might help.

Eli-Zaretskii commented 4 years ago

Sounds like some face has an invalid definition. I suggest to find out which face(s) are being merged here; the test case and the backtrace don't give enough info to understand that.

yyoncho commented 4 years ago

@jiacai2050 can you test with default theme(e. g. after M-x disable-theme)?

In case you still see the error, can you test after setting lsp-diagnostic-package to :none? I suspect that we might be somehow generating invalid face when we generate dynamically flycheck face for the tagged diagnostics.

Eli-Zaretskii commented 4 years ago

Actually, I see maybe_produce_line_number in the backtrace, so it sounds like the offending face is probably line-number. Can the OP please show the definition of that face in the session that crashes?

(Sorry for not noticing maybe_produce_line_number when I first looked at the backtrace.)

jiacai2050 commented 4 years ago 
(load-theme 'wombat t)
(custom-set-faces '(hl-line ((t (:foreground nil :underline t :background "#111"))))
                  '(region ((t (:background "blue")))))

@yyoncho FYI, I'm using wombat theme for a long time, will retry reproduce this issue with default theme.

Eli-Zaretskii commented 4 years ago

If this is the recipe for reproducing the 100% CPU problem, then I cannot reproduce that. I guess it could be macOS-specific?

wyuenho commented 3 years ago

This might have something to do with the 

(while-no-input
    (redisplay)
    ...

idiom. Historically there seems to be a lot of hangs at wait_reading_process_output reported since at least the days of Emacs 23. I wonder why. I can't decipher this convoluted C code.

Eli-Zaretskii commented 3 years ago

Where did you see the above idiom in any code involved in the issue discussed here?

wyuenho commented 3 years ago

I'm running a fork of window-purpose that has this block wrapping a post-command-hook. You can look at the history, before I added this block, my Emacs was slow but didn't freeze, after adding this block, it freezes on a MacPorts compiled Emac 27 NS port every 15 minutes or so, and Emacs becomes unusable.

This is how I set up window-purpose:

;; My window-purpose fork requires this imenu-list fork
(use-package imenu-list
  :quelpa (imenu-list :fetcher github :repo "wyuenho/imenu-list" :branch "clear-buffer"))

(use-package window-purpose
  :quelpa (window-purpose :fetcher github :repo "wyuenho/emacs-purpose" :files (:defaults "layouts")
                          :branch "improve-code1")
  :config
  (purpose-x-code1-setup)
  (purpose-x-popwin-setup)
  (purpose-x-kill-setup)
  (purpose-x-magit-single-on)

  (purpose-mode 1))

After I kill Emacs, there's a stacktrace very similar to this and this thread's show up. Since this issue is still happening on the latest emacs-27 branch, I'm testing the export LIBXML2_CFLAGS solution at the bottom and see if it makes a difference. I have been using this solution for about a day now and haven't seen any freezing yet.

I've been trying to hunt down the cause of this issue for months now and it's driving me crazy.

wyuenho commented 3 years ago

Nevermind, I simultaneously ran into this problem and another freeze very similar to the StackOverflow post after the while-no-input block was put in place.

This problem seems to have been fixed in https://github.com/emacs-mirror/emacs/commit/3711339f92be0c50633aefae991d8fa4a135fe33

Xeite commented 3 years ago

@yyoncho After I upgrade latest lsp-mode, lsp-java I encountered exactly same thing as @jiacai2050 decsribed. When I disabled theme, it now looks working again. It did freeze as well even it seems to take longer time.

And :none to lsp-diagnostic-package did not work too.

Xeite commented 3 years ago

I manually downgrade lsp-mode to 6.3.1, and confirmed that it's working again. There might be some bug somwhere between the commits.

yyoncho commented 3 years ago

@Xeite do you have a config + steps to reproduce?

wyuenho commented 3 years ago

@Xeite would be nice if you could git bisect to a commit too

Xeite commented 3 years ago

@wyuenho I'm bisecting lsp-mode codebase, but I saw some conflict with lsp-java (I commented out 1~2 lines to ignore the errors and keep trying though). Is there release guide to match both packages?

@yyoncho I will try again with minimal config to reproduce once I can't pinpoint the commit.

wyuenho commented 3 years ago

@Xeite do you see the same stacktrace tho? Cos I haven't seen it since emacs-mirror/emacs@3711339

Xeite commented 3 years ago

@wyuenho Yes I tried to compile emacs@master which contains the commit you mentioned, but it did not work. (same stacktrace).

I'm bisecting commits, so keep me posting later.

Xeite commented 3 years ago

It's weird that I could not find suspected commit without any problem for all commits :\ Only difference during the time was editing pattern (I wrote org file while keep jumping around codes when the freeze existed), but hardly believe it makes difference.

ch1bo commented 3 years ago

I'm having the same issue and my profile hints onto lsp-treemacs being the issue:

- #<compiled 0x105e1e9>                                                                        7263  92%
 - lsp--parser-on-message                                                                      7259  92%
  - lsp--on-notification                                                                       7237  92%
   - lsp--on-diagnostics                                                                       7237  92%
    - run-hooks                                                                                7237  92%
     - lsp-treemacs--after-diagnostics                                                         7237  92%
      - treemacs-update-node                                                                   7237  92%
       - treemacs-expand-lsp-error-list                                                        7236  92%
        - treemacs--do-expand-lsp-error-list                                                   7236  92%
         - lsp-treemacs--root-folders                                                          7236  92%
          - -map                                                                               7236  92%
           - mapcar                                                                            7236  92%
            - #<compiled 0x10e33b5>                                                            7236  92%
             - lsp-treemacs--face                                                              7236  92%
              - -keep                                                                          7236  92%
               - #<compiled 0x10e34f5>                                                         7236  92%
                + -min-by                                                                      5864  74%
  + #<compiled 0x114440d>                                                                        22   0%
+ timer-event-handler                                                                           273   3%
+ command-execute                                                                               139   1%
+ ...                                                                                           112   1%
+ redisplay_internal (C function)                                                                31   0%
+ which-key--hide-popup                                                                           3   0%
+ evil--jump-hook                                                                                 2   0%
+ #<compiled 0x1fd4524f6435>                                                                      1   0%
+ company-post-command                                                                            1   0%

Will try newer versions for lsp-treemacs and lsp-mode (which is transitively depending on the former?)

yyoncho commented 3 years ago

@ch1bo update your lsp-treemacs version. The old implementation of the errors list had perf issues. lsp-mode does not depend on lsp-treemacs - lsp-mode is firing hooks and any package can subscribe to them.

ch1bo commented 3 years ago

@yyoncho Ok, was just confused how it ended up in my doom-emacs setup.

Anyways updated lsp-treemacs e0486d7 -> 10c34fc and seems to fine now :+1:

aaronjensen commented 3 years ago

Just hit a similar 100% cpu usage. My trace is a little different.

I'm rebuilding w/ debug info in case I hit it again. For what it's worth, Emacs was like this when I woke up in the morning and woke my computer from sleep. Not sure if that helps.

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x000000010a0c973d emacs`assq_no_quit [inlined] TAGGEDP(a=0x00007fae7241ab53, tag=Lisp_Cons) at lisp.h:752:10 [opt]
  * frame #1: 0x000000010a0c973d emacs`assq_no_quit [inlined] CONSP(x=0x00007fae7241ab53) at lisp.h:1379 [opt]
    frame #2: 0x000000010a0c973d emacs`assq_no_quit(key=0x00000000027d4f50, alist=0x00007fae7241ab63) at fns.c:1697 [opt]
    frame #3: 0x000000010a030da3 emacs`get_lface_attributes [inlined] lface_from_face_name_no_resolve(f=0x00007fae83459230, face_name=0x00000000027d4f50, signal_p=false) at xfaces.c:0 [opt]
    frame #4: 0x000000010a030d85 emacs`get_lface_attributes [inlined] get_lface_attributes_no_remap(f=0x00007fae83459230, face_name=0x00000000027d4f50, attrs=0x00007ffee5c88f70, signal_p=false) at xfaces.c:2007 [opt]
    frame #5: 0x000000010a030d85 emacs`get_lface_attributes(w=<unavailable>, f=0x00007fae83459230, face_name=0x00000000027d4f50, attrs=0x00007ffee5c88f70, signal_p=false, named_merge_points=<unavailable>) at xfaces.c:2058 [opt]
    frame #6: 0x000000010a035082 emacs`merge_named_face(w=0x00007fae13047a58, f=0x00007fae83459230, face_name=0x00000000027d4f50, to=0x00007ffee5c896a0, named_merge_points=0x00007ffee5c88f58, attr_filter=<no summary available>) at xfaces.c:2336:17 [opt]
    frame #7: 0x000000010a0319bd emacs`merge_face_ref(w=<unavailable>, f=0x00007fae83459230, face_ref=0x00000000027d4f50, to=0x00007ffee5c896a0, err_msgs=false, named_merge_points=0x00007ffee5c891b8, attr_filter=<no summary available>) at xfaces.c:2832:12 [opt]
    frame #8: 0x000000010a02ed3e emacs`merge_face_vectors(w=<unavailable>, f=<unavailable>, from=0x00007ffee5c891d0, to=0x00007ffee5c896a0, named_merge_points=<unavailable>) at xfaces.c:2207:5 [opt]
    frame #9: 0x000000010a0350fb emacs`merge_named_face(w=0x00007fae13047a58, f=0x00007fae83459230, face_name=0x00007fad67beb720, to=0x00007ffee5c896a0, named_merge_points=0x00007ffee5c891b8, attr_filter=<no summary available>) at xfaces.c:2348:9 [opt]
    frame #10: 0x000000010a0319bd emacs`merge_face_ref(w=<unavailable>, f=0x00007fae83459230, face_ref=0x00007fad67beb720, to=0x00007ffee5c896a0, err_msgs=true, named_merge_points=0x0000000000000000, attr_filter=<no summary available>) at xfaces.c:2832:12 [opt]
    frame #11: 0x000000010a031bac emacs`merge_face_ref(w=<unavailable>, f=0x00007fae83459230, face_ref=<unavailable>, to=0x00007ffee5c896a0, err_msgs=true, named_merge_points=0x0000000000000000, attr_filter=<no summary available>) at xfaces.c:2824:10 [opt]
    frame #12: 0x000000010a034256 emacs`face_at_buffer_position(w=0x00007fae13047a58, pos=<unavailable>, endptr=0x00007ffee5c89790, limit=<unavailable>, mouse=false, base_face_id=33, attr_filter=<no summary available>) at xfaces.c:6439:5 [opt]
    frame #13: 0x0000000109fbe4c6 emacs`face_at_pos(it=0x00007ffee5c89868, attr_filter=<no summary available>) at xdisp.c:4366:14 [opt]
    frame #14: 0x0000000109fbd614 emacs`handle_face_prop(it=0x00007ffee5c89868) at xdisp.c:4462:27 [opt]
    frame #15: 0x0000000109fbc6eb emacs`handle_stop(it=0x00007ffee5c89868) at xdisp.c:3841:14 [opt]
    frame #16: 0x0000000109f96dea emacs`init_iterator [inlined] reseat(it=<unavailable>, pos=<unavailable>, force_p=<unavailable>) at xdisp.c:7087:4 [opt] [artificial]
    frame #17: 0x0000000109f8d450 emacs`start_display(it=0x00007ffee5c89868, w=<unavailable>, pos=(charpos = 1, bytepos = 1)) at xdisp.c:3458:3 [opt]
    frame #18: 0x000000010a07dfe0 emacs`line_number_display_width(w=0x00007fae13047a58, width=0x00007ffee5c8abd8, pixel_width=0x00007ffee5c8abdc) at indent.c:1990:7 [opt]
    frame #19: 0x000000010a07de69 emacs`Fline_number_display_width(pixelwise=0x0000000000000000) at indent.c:2021:3 [opt]
    frame #20: 0x000000010a0c14ad emacs`funcall_subr(subr=0x000000010a1dfff8, numargs=0, args=<unavailable>) at eval.c:2984:19 [opt]
    frame #21: 0x000000010a0c0a81 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2911:11 [opt]
    frame #22: 0x000000010a104e40 emacs`exec_byte_code(bytestr=<unavailable>, vector=0x00007fae843cda8d, maxdepth=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:632:12 [opt]
    frame #23: 0x000000010a0c1a04 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3033:10 [opt] [artificial]
    frame #24: 0x000000010a0c0a1f emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt]
    frame #25: 0x000000010a0c0baf emacs`Frun_hook_with_args at eval.c:0 [opt]
    frame #26: 0x000000010a0c0ba0 emacs`Frun_hook_with_args(nargs=1, args=0x00007ffee5c8ae18) at eval.c:2594 [opt]
    frame #27: 0x000000010a0c0af5 emacs`Frun_hooks [inlined] run_hook(hook=0x00007fad79deaa20) at eval.c:2742:3 [opt]
    frame #28: 0x000000010a0c0ae8 emacs`Frun_hooks(nargs=1, args=0x00007ffee5c8aef8) at eval.c:2576 [opt]
    frame #29: 0x000000010a0c0a81 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2911:11 [opt]
    frame #30: 0x000000010a104e40 emacs`exec_byte_code(bytestr=<unavailable>, vector=0x00007fae84223765, maxdepth=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:632:12 [opt]
    frame #31: 0x000000010a0c1a04 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3033:10 [opt] [artificial]
    frame #32: 0x000000010a0c0a1f emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt]
    frame #33: 0x000000010a104e40 emacs`exec_byte_code(bytestr=<unavailable>, vector=0x00007fae821f8905, maxdepth=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:632:12 [opt]
    frame #34: 0x000000010a0c173d emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=0x00007fae821f89a5, syms_left=0x0000000000000000, nargs=0, args=0x0000000000000000) at eval.c:3033:10 [opt]
    frame #35: 0x000000010a0c1711 emacs`funcall_lambda(fun=0x00007fae821f89a5, nargs=<unavailable>, arg_vector=0x00007ffee5c8b298) at eval.c:3183 [opt]
    frame #36: 0x000000010a0c0a1f emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt]
    frame #37: 0x000000010a0c05d0 emacs`Fapply(nargs=3, args=0x00007ffee5c8b388) at eval.c:2541:24 [opt]
    frame #38: 0x000000010a0c0a81 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2911:11 [opt]
    frame #39: 0x000000010a104e40 emacs`exec_byte_code(bytestr=<unavailable>, vector=0x00007fae821f8595, maxdepth=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:632:12 [opt]
    frame #40: 0x000000010a0c1a04 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3033:10 [opt] [artificial]
    frame #41: 0x000000010a0c0a1f emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt]
    frame #42: 0x000000010a0c05d0 emacs`Fapply(nargs=2, args=0x00007ffee5c8b568) at eval.c:2541:24 [opt]
    frame #43: 0x000000010a0c0a81 emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:2911:11 [opt]
    frame #44: 0x000000010a104e40 emacs`exec_byte_code(bytestr=<unavailable>, vector=0x00007fae822fac5d, maxdepth=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:632:12 [opt]
    frame #45: 0x000000010a0c1a04 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3033:10 [opt] [artificial]
    frame #46: 0x000000010a0c0a1f emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt]
    frame #47: 0x000000010a104e40 emacs`exec_byte_code(bytestr=<unavailable>, vector=0x00007fae84223525, maxdepth=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:632:12 [opt]
    frame #48: 0x000000010a0c1a04 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3033:10 [opt] [artificial]
    frame #49: 0x000000010a0c0a1f emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt]
    frame #50: 0x000000010a104e40 emacs`exec_byte_code(bytestr=<unavailable>, vector=0x00007fadc1b182ad, maxdepth=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:632:12 [opt]
    frame #51: 0x000000010a0c1a04 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3033:10 [opt] [artificial]
    frame #52: 0x000000010a0c0a1f emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt]
    frame #53: 0x000000010a104e40 emacs`exec_byte_code(bytestr=<unavailable>, vector=0x00007fae84222e05, maxdepth=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:632:12 [opt]
    frame #54: 0x000000010a0c1a04 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3033:10 [opt] [artificial]
    frame #55: 0x000000010a0c0a1f emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt]
    frame #56: 0x000000010a104e40 emacs`exec_byte_code(bytestr=<unavailable>, vector=0x00007fae8422321d, maxdepth=<unavailable>, args_template=<unavailable>, nargs=<unavailable>, args=<unavailable>) at bytecode.c:632:12 [opt]
    frame #57: 0x000000010a0c1a04 emacs`funcall_lambda [inlined] fetch_and_exec_byte_code(fun=<unavailable>, syms_left=<unavailable>, nargs=<unavailable>, args=<unavailable>) at eval.c:3033:10 [opt] [artificial]
    frame #58: 0x000000010a0c0a1f emacs`Ffuncall(nargs=<unavailable>, args=<unavailable>) at eval.c:0:4 [opt]
    frame #59: 0x000000010a0c05d0 emacs`Fapply(nargs=2, args=0x00007ffee5c8c188) at eval.c:2541:24 [opt]
    frame #60: 0x000000010a0bc185 emacs`apply1(fn=<unavailable>, arg=<unavailable>) at eval.c:2757:43 [opt]
    frame #61: 0x000000010a0bf03f emacs`internal_condition_case_1(bfun=(emacs`read_process_output_call at process.c:5929), arg=0x00007fae01c4b953, handlers=0x0000000000000090, hfun=(emacs`read_process_output_error_handler at process.c:5935)) at eval.c:1467:25 [opt]
    frame #62: 0x000000010a10fac2 emacs`read_process_output [inlined] read_and_dispose_of_process_output(p=<unavailable>, chars="-dir /Users/aaronjensen/Source/tmp/gem-repro/ -nowait -current-frame -tty /dev/ttys007 xterm-256color -file Gemfile.lock \nd by ‘savehist’.\n\n(setq savehist-minibuffer-history-variables '(read-from-kill-ring-history woman-topic-history Info-search-history xref--read-identifier-history consult--man-history consult--apropos-history consult--imenu-history consult--find-history regexp-history consult--buffer-history consult--grep-history consult--line-history org-journal-search-history counsel-imenu-history imenu--history-list org-capture--prompt-history buffer-name-history goto-line-history extended-command-history face-name-history git-commit-read-ident-history ert--selector-history org-read-date-history transient--history find-args-history org-link--history read-expression-history org-refile-history read-char-history swiper-history counsel-describe-symbol-history counsel-org-goto-history minibuffer-history evil-ex-history counsel-git-grep-history file-name-history evil-ex-search-history magit-revision-histor"..., nbytes=<unavailable>, coding=0x00007fae0145dc70) at process.c:6153:5 [opt]
    frame #63: 0x000000010a10f91d emacs`read_process_output(proc=0x00007fae01fd3aa5, channel=<unavailable>) at process.c:6063 [opt]
    frame #64: 0x000000010a10e460 emacs`wait_reading_process_output(time_limit=<unavailable>, nsecs=<unavailable>, read_kbd=-1, do_display=true, wait_for_cell=<unavailable>, wait_proc=<unavailable>, just_wait_proc=0) at process.c:5749:16 [opt]
    frame #65: 0x000000010a03ec7a emacs`read_char [inlined] kbd_buffer_get_event(kbp=<unavailable>, used_mouse_menu=0x00007ffee5c8cc8f, end_time=0x0000000000000000) at keyboard.c:0 [opt]
    frame #66: 0x000000010a03ea9e emacs`read_char [inlined] read_event_from_main_queue(end_time=0x0000000000000000, local_getcjmp=0x00007ffee5c8c910, used_mouse_menu=0x00007ffee5c8cc8f) at keyboard.c:2159 [opt]
    frame #67: 0x000000010a03e978 emacs`read_char at keyboard.c:2223 [opt]
    frame #68: 0x000000010a03e978 emacs`read_char(commandflag=1, map=0x00007fae01b6b033, prev_event=0x0000000000000000, used_mouse_menu=0x00007ffee5c8cc8f, end_time=0x0000000000000000) at keyboard.c:2833 [opt]
    frame #69: 0x000000010a03b492 emacs`read_key_sequence(keybuf=<unavailable>, prompt=0x0000000000000000, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<unavailable>) at keyboard.c:9484:12 [opt]
    frame #70: 0x000000010a039d1c emacs`command_loop_1 at keyboard.c:1353:15 [opt]
    frame #71: 0x000000010a0bef07 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1239), handlers=0x0000000000000090, hfun=(emacs`cmd_error at keyboard.c:922)) at eval.c:1443:25 [opt]
    frame #72: 0x000000010a049b00 emacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1094:11 [opt]
    frame #73: 0x000000010a0be6d2 emacs`internal_catch(tag=0x000000000000cb40, func=(emacs`command_loop_2 at keyboard.c:1090), arg=0x0000000000000000) at eval.c:1187:25 [opt]
    frame #74: 0x000000010a1849b5 emacs`recursive_edit_1.cold.1 at keyboard.c:1073:2 [opt]
    frame #75: 0x000000010a038de9 emacs`recursive_edit_1 [inlined] command_loop at keyboard.c:1070:5 [opt]
    frame #76: 0x000000010a038de4 emacs`recursive_edit_1 at keyboard.c:720 [opt]
    frame #77: 0x000000010a038f7b emacs`Frecursive_edit at keyboard.c:789:3 [opt]
    frame #78: 0x000000010a037ff3 emacs`main(argc=<unavailable>, argv=<unavailable>) at emacs.c:2050:3 [opt]
    frame #79: 0x00007fff70669cc9 libdyld.dylib`start + 1
wyuenho commented 3 years ago

This doesn't look related to LSP at all. I had run into hangs and crashes on emacs 27.1 before, apparently there was a memory leak issue what was fixed on master and the emacs27 branch. Since then I've only seen one hang, but after reinstalling all packages, I haven't seen that again.

aaronjensen commented 3 years ago

I wouldn't have thought it, it's just where I landed via google when looking for the error. I'll report to Emacs as well, though w/o additional trace info I doubt they'll be able to help much. I'm on Emacs 28/master.

Eli-Zaretskii commented 3 years ago

What Emacs version is that? And what is the definition of the line-number face?

aaronjensen commented 3 years ago

What Emacs version is that?

28/master

And what is the definition of the line-number face?

           Family: unspecified
          Foundry: unspecified
            Width: unspecified
           Height: unspecified
           Weight: unspecified
            Slant: unspecified
       Foreground: #505050
DistantForeground: unspecified
       Background: #f8f8f8
        Underline: unspecified
         Overline: unspecified
   Strike-through: unspecified
              Box: unspecified
          Inverse: unspecified
          Stipple: unspecified
             Font: unspecified
          Fontset: unspecified
           Extend: unspecified
          Inherit: default

Is there a better way to print the definition?

Here is my default:

           Family: JetBrains Mono NL
          Foundry: nil
            Width: normal
           Height: 150
           Weight: normal
            Slant: normal
       Foreground: #000000
DistantForeground: unspecified
       Background: #ffffff
        Underline: nil
         Overline: nil
   Strike-through: nil
              Box: nil
          Inverse: nil
          Stipple: nil
             Font: #<font-object -*-JetBrains Mono NL-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1>
          Fontset: -*-JetBrains Mono NL-normal-normal-normal-*-15-*-*-*-m-0-fontset-startup
           Extend: nil
          Inherit: nil
Eli-Zaretskii commented 3 years ago

I meant the Lisp definitions of the face (in case there's something strange there), but the above should suffice, I think.

The backtrace shows Emacs seems to be looping in assq_no_quit, so maybe your frame's face-alist is somehow screwed? What else can explain a loop there?

In other words, I don't really have a clue given the data you presented. Can you step through the infloop in the debugger and see what's going on?

aaronjensen commented 3 years ago

Unfortunately, I couldn't sort through what was going on w/o debug symbols. Stepping through it looked like the list provided to assq_no_quit never ended.

From assq_no_quit:

/* Like Fassq but never report an error and do not allow quits.
   Use only on objects known to be non-circular lists.  */

I'd guess that Vface_remapping_alist ended up being a circular list, but no idea how.

Eli-Zaretskii commented 3 years ago

I'd guess that Vface_remapping_alist ended up being a circular list, but no idea how.

Could be, but we need evidence.

And the function that loops doesn't search face-remapping-alist, it searches face-new-frame-defaults, which is managed by Emacs and shouldn't become corrupted.

aaronjensen commented 3 years ago

And the function that loops doesn't search face-remapping-alist, it searches face-new-frame-defaults, which is managed by Emacs and shouldn't become corrupted.

I'm referring to this, isn't that searching face-remapping-alist?

  /* See if SYMBOL has been remapped to some other face (usually this
     is done buffer-locally).  */
  face_remapping = assq_no_quit (face_name, Vface_remapping_alist);
aaronjensen commented 3 years ago

I have only a single setq for face-remapping-alist in all of my packages as far as I can tell:

    (setq-local face-remapping-alist `((header-line lsp-ui-doc-header)))
Eli-Zaretskii commented 3 years ago

This part of the backtrace:

  * thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
      frame #0: 0x000000010a0c973d emacs`assq_no_quit [inlined] TAGGEDP(a=0x00007fae7241ab53, tag=Lisp_Cons) at lisp.h:752:10 [opt]
    * frame #1: 0x000000010a0c973d emacs`assq_no_quit [inlined] CONSP(x=0x00007fae7241ab53) at lisp.h:1379 [opt]
      frame #2: 0x000000010a0c973d emacs`assq_no_quit(key=0x00000000027d4f50, alist=0x00007fae7241ab63) at fns.c:1697 [opt]
      frame #3: 0x000000010a030da3 emacs`get_lface_attributes [inlined] lface_from_face_name_no_resolve(f=0x00007fae83459230, face_name=0x00000000027d4f50, signal_p=false) at xfaces.c:0 [opt]

seems to indicate that the looping call to assq_no_quit is in lface_from_face_name_no_resolve, where there's no reference to face-remapping-alist.

aaronjensen commented 3 years ago

Ah, when it's inlined it doesn't get its own line. I missed that, thanks. So it's either f->face_alist or face-new-frame-defaults, as you mentioned.

Well, hopefully it happens again while I'm running a debug build. I don't like running a debug build because of how slow it is so I don't run it very often... Also, it appears -Og doesn't let me access variables in higher stack frames either, so I have to run with -O0.

By the way, what values do you want to see and how do I view them with the lisp #define macros? And, is there a way to tell what type a Lisp_Object is so I know which macro to use?

Eli-Zaretskii commented 3 years ago

With lldb, it's hard: you will need to do the bit stuff yourself to see which object each variable is. GDB is much better, but I don't know if you can find a workable port. Try reading the relevant commands in src/.gdbinit and do that by hand. The xtype command shows the type, and then there's an xSOMETHING command for each object type: xstring from strings, xcar andxcdrfor cons cells,xsymbol` for symbols, etc.

jimeh commented 3 years ago

I've had this issue appearing since about 3-4 weeks ago. It mostly happens right after running lsp-workspace-restart which is sometimes needed to get Go's gopls server to pickup changes to dependencies within a project. I am running the native-comp branch of Emacs in case that matters.

In my case though, the issue seems to be that lsp-mode is just repeatedly printing the same message over and over to the *Messages* buffer:

LSP :: Sending to process failed with the following error: Process gopls not running

It makes emacs suuuuuuuuper slow, and basically not usable. Killing all language servers doesn't help either, only fix is to restart Emacs from scratch.

Here's an example from my *Messages* buffer:

LSP :: Sending to process failed with the following error: Process gopls not running [2064 times]
tabs: 0:nil 1:dot 2:emacs 3:notes 4:katapult 5:go-katapult 6:tf-katapult 7:apps-api 8:central-metrics 9:metritool [2 times]
LSP :: Sending to process failed with the following error: Process gopls not running [344 times]
Waiting for process to die...done
LSP :: Sending to process failed with the following error: Process gopls not running [4472 times]
Please type y, n, or !: n
File digest doesn’t match, so undo history will be discarded.
LSP :: Sending to process failed with the following error: Process gopls not running [5504 times]
Quit
LSP :: Sending to process failed with the following error: Process gopls not running [4816 times]
Collapse node
LSP :: Sending to process failed with the following error: Process gopls not running [4128 times]
tabs: 0:nil 1:dot 2:emacs 3:notes 4:katapult 5:go-katapult 6:tf-katapult 7:apps-api 8:central-metrics 9:metritool [2 times]
LSP :: Sending to process failed with the following error: Process gopls not running [1032 times]
Mark set
LSP :: Sending to process failed with the following error: Process gopls not running [344 times]
Mark set
LSP :: Sending to process failed with the following error: Process gopls not running [6536 times]
Quit
LSP :: Sending to process failed with the following error: Process gopls not running [344 times]
Mark set
LSP :: Sending to process failed with the following error: Process gopls not running [1032 times]
jakejx commented 3 years ago

FWIW I am running into the same issue with many LSP :: Sending to process failed with the following error: Process gopls not running messages. Emacs also slows to a crawl when that happens so it's hard to identify the root cause.

Anecdotally, it seems to happen after I jump definition to a file that is not part of the current workspace.

yyoncho commented 3 years ago

@jakejx - I am seeing that issue from time to time when restarting workspace, I will investigate it

kurnevsky commented 3 years ago

My emacs hangs this way regularly when I work with lsp-treemacs errors list. Often it happens when I press q when it's being updated. Also sometimes it hangs when creating dap-mode windows.