pylsp-snap 28.2 interaction problem

[mazerj]

I'm still trying to track this down, but yesterday I updated the snap from 28.1 to 28.2 (linux mint cinnamon 20.2) and suddenly having problems where the pylsp server used by python mode locks up the emacs session. It's something very specific related to triple-quote comment blocks occurring inside a function or class..

Sorry for vague issue, but I'm still trying to find minimal example (will add here when I do), but reverting to 28.1 problem went away, so I'm pretty sure it's about something that changed between emacs snap 28.1->28.2 and not related to pylsp, which hasn't been touched on my machine (v1.4.1, installed from pip).

Wanted to get this out there, because it's a hard lock -- have to kill the process from a shell, so potentially can loose files/data with this one..

Will follow up with more details.

jamie

[alexmurray]

Thanks for reporting this issue. Can you try deleting/moving aside any old bytecode (.elc) files and see if this helps?

[alexmurray]

@mazerj did you have a chance to try my suggestion above? is this still an issue for you?

[mazerj]

Sorry, I got side tracked and needed to finish some stuff, so I just downgraded back to 28.1. I can give it a try over the weekend, if that's useful. Am I still the only one seeing this?

[alexmurray]

I haven't received any similar reports so I think you may be the only one. Let me know what you find.

[mazerj]

Hi Alex, I finally got around to tracking down a minimal test file that generates the lockup. When I open this file with the 28.2 build (2022-12-08) it hard locks up my emacs session. It has something to do with lsp choking on the various comments -- unterminated ` or """ (say while your writing the comment). Have to kill the process to recover, loosing files..

Here's the example:

def Foo:
    # comment out next line and works ok, incomplete comment -> locks up
    """
    pass

class Bar:
    labelmasks: torch.Tensor
    """blah blah blah - single line common ok, >1 line locks up
    """  

class Baz:
    def __init__(self):
    """apostrophe in this quote causes lock up. It's better to..."""
    pass

[mazerj]

@alexmurray By the way -- I completely got rid of my entire ~/.emacs.d dir and opened a file containing the fragment above from bash and it freezes immediately. If you save that frag to foo.py and just do emacs foo.py, it should lock up (or does on my mint installation).

[alexmurray]

Apologies for radio silence on this issue. Can you confirm if this is still affecting you?

[mazerj]

Yep. Save that fragment to a file and just open it with emacs -q frag.py and it hard locks up my emacs... have to kill -9 it... Just for the record:

$ snap list
Name    Version    Rev    Tracking       Publisher    Notes
core    16-2.58.3  14946  latest/stable  canonical✓   core
core18  20230320   2721   latest/stable  canonical✓   base
core20  20230308   1852   latest/stable  canonical✓   base
emacs   28.2       1905   latest/stable  alexmurray✪  classic

[alexmurray]

FWIW I can reproduce this running the emacs 28.2 deb on Ubuntu 23.04 - so this doesn't seem specific to the snap.

Also I was able to get a backtrace by sending SIGUSR2 to emacs (killall -SIGUSR2 emacs):

Debugger entered--entering a function:
* #f(compiled-function () #<bytecode 0xb89c776646fa45a>)()
  syntax-ppss()
  python-nav-end-of-statement()
  python-nav-end-of-block()
  python-info-statement-ends-block-p()
  python-nav--forward-sexp(-1 nil nil)
  python-nav-forward-sexp(-1 nil nil)
  python-nav-backward-sexp()
  python-info-docstring-p((0 nil 218 34 nil nil 0 nil 225 nil nil))
  python-font-lock-syntactic-face-function((0 nil 218 34 nil nil 0 nil 225 nil nil))
  font-lock-fontify-syntactically-region(11 348 nil)
  font-lock-default-fontify-region(17 348 nil)
  font-lock-fontify-region(17 348)
  #f(compiled-function (fun) #<bytecode 0x19b615a2f4ce00fd>)(font-lock-fontify-region)
  jit-lock--run-functions(17 348)
  jit-lock-fontify-now(17 1517)
  jit-lock-function(17)
  line-move-partial(1 nil)
  line-move(1 nil nil 1)
  next-line(1 1)
  funcall-interactively(next-line 1 1)
  command-execute(next-line)

I can also reproduce it when running the snap from the beta channel which is based on the emacs-29 upstream branch so it seems this is still not known about upstream. As such, it would be worth reporting this upstream (M-x report-emacs-bug).

I will close this issue as it is not specific to the emacs snap.

[mazerj]

I know this is closed, but just wanted to follow up with the emacs bug report info. My report can be found here: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63363

There were two immediate responses - one saying this looks like https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62325, which it definitely does. The chain seems to indicate this should be fixed in emacs29, which seems strange, since if I'm reading your last response right, it still fails for you with 29..

[mazerj]

And just out of curiosity, I pulled down a 28.2 flatpak just now and it does exactly the same thing as the 28.2 snap. So don't know what's different about the guy saying he can't replicate (on his custom debian build).

[mazerj]

@alexmurray Sorry -- I figured out the channels stufff. I just installed stable/beta snap and when I open that test file (emac -Q), it seems to be ok. So perhaps it is fixed upstream? Could you double check that you're still locking up on 29? My beta snap right now is reporting 29.0.90 ... 2023-05-07 build. Just want to let the emacs devs know whether or not they still need to track this down.. thanks.

[alexmurray]

Ah you are right - sorry I am not sure how I tested it before but it definitely seems to be working fine now with emacs from the beta channel (29.0.90-emacs-29-7d6855c) - cheers.