Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emacs freezes on displaying docstring #9

Closed
samaaron opened this issue Sep 21, 2012 · 4 comments
Closed

Emacs freezes on displaying docstring #9

samaaron opened this issue Sep 21, 2012 · 4 comments

Comments

@samaaron
Copy link
Contributor

Now I'm starting to see Emacs freeze on autocompleting stuff.

I see the following Clojure stacktrace, and Emacs hangs. I assume that Emacs is waiting for a reply from the Clojure process which isn't being received due to this error. If this is the case, perhaps it's worth looking into adding timeouts to the synchronous comms?

Exception in thread "nREPL-worker-1" java.lang.NullPointerException
    at clojure.core$refer.doInvoke(core.clj:3775)
    at clojure.lang.RestFn.applyTo(RestFn.java:139)
    at clojure.core$apply.invoke(core.clj:602)
    at clojure.core$load_lib.doInvoke(core.clj:5252)
    at clojure.lang.RestFn.applyTo(RestFn.java:142)
    at clojure.core$apply.invoke(core.clj:602)
    at clojure.core$load_libs.doInvoke(core.clj:5271)
    at clojure.lang.RestFn.applyTo(RestFn.java:137)
    at clojure.core$apply.invoke(core.clj:604)
    at clojure.core$use.doInvoke(core.clj:5363)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at clojure.main$repl.doInvoke(main.clj:258)
    at clojure.lang.RestFn.invoke(RestFn.java:1096)
    at clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__337.invoke(interruptible_eval.clj:51)
    at clojure.lang.AFn.applyToHelper(AFn.java:159)
    at clojure.lang.AFn.applyTo(AFn.java:151)
    at clojure.core$apply.invoke(core.clj:600)
    at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1769)
    at clojure.lang.RestFn.invoke(RestFn.java:425)
    at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:36)
    at clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__374$fn__376.invoke(interruptible_eval.clj:164)
    at clojure.core$comp$fn__3758.invoke(core.clj:2276)
    at clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__367.invoke(interruptible_eval.clj:131)
    at clojure.lang.AFn.run(AFn.java:24)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:680)
@purcell
Copy link
Member

purcell commented Sep 22, 2012

That doesn't look like anything a timeout would mitigate. Looks like a crash inside nrepl, and not specific to ac-nrepl. There might be more details in the stacktrace of the wrapped NPE, but getting at it is another issue...

When nrepl.el fires off a request, it's perfectly capable of detecting exceptions thrown in the code it sent. In the above case, nrepl itself has obviously crapped out and so the async "done" response never got to nrepl.el.

FWIW, there was never any support in Slime for timeouts, because it was perfectly valid (if ill-advised) to execute a long-running synchronous command.

@samaaron
Copy link
Contributor Author

A timeout might allow me to get control of Emacs back - rather than having to totally kill it and restart it (which seems to be my only option when it hangs like that).

Do you know how we can get at the NPE?

@purcell
Copy link
Member

purcell commented Sep 22, 2012

I agree that the timeout would help in this case, but if the backend is broken like this, then all bets are off. I believe that's why Slime never had any safeguards against implementation bugs in the swank backends.

If I were trying to track down the NPE, I'd open up the source of one of the functions in the above stacktrace (e.g. clojure.tools.nrepl.middleware.interruptible_eval/evaluate), add a catch and println there, and then evaluate the new function definition from within nrepl. With any luck it would take effect immediately.

@samaaron
Copy link
Contributor Author

samaaron commented Oct 4, 2012

Through a combination of nrepl.el updates and upgrading lein to the latest preview, this issue seems to have disappeared. Happy happy joy joy!

@samaaron samaaron closed this as completed Oct 4, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants