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

cider 0.8.1 does not accurately display errors #895

Closed
pbostrom opened this issue Nov 24, 2014 · 48 comments
Closed

cider 0.8.1 does not accurately display errors #895

pbostrom opened this issue Nov 24, 2014 · 48 comments
Labels

Comments

@pbostrom
Copy link

I created a project using the default lein template and then added and attempted to evaluate a bad expression. The reporting does not seem to be working. Here is the code:

(ns cider-fail.core)

(defn foo
  "I don't do a whole lot."
  [x]
  (println x "Hello, World!"))


(foo (1 2 3))

When I evaluate this, the cider-error buffer pops up but it is empty. If I switch back to the cider-repl buffer then I can see the error, but it's pointing to the wrong line number. The line number differs depending on if I evaluate the whole buffer C-c C-k or just evaluate the single expression C-c C-e. Both reported line numbers point to valid code, and the line containing the actual error (an unquoted list of numbers passed as an argument) is never highlighted. See attached screenshots.
screen shot 2014-11-24 at 1 00 34 pm
screen shot 2014-11-24 at 1 02 26 pm
screen shot 2014-11-24 at 12 59 52 pm

@bbatsov
Copy link
Member

bbatsov commented Nov 25, 2014

This is a Clojure bug. See http://dev.clojure.org/jira/browse/CLJ-1568. If you'd like to see it fixed I'd suggest upvoting the ticket.

@pbostrom
Copy link
Author

Ah, ok. What about the issue with the empty cider-error buffer (see the third attachment)? This seemed to start happening with the 0.8 release.

@bbatsov
Copy link
Member

bbatsov commented Nov 25, 2014

I can't reproduce the problem with the missing stacktrace buffer.

@bbatsov
Copy link
Member

bbatsov commented Nov 25, 2014

You can check your *nrepl-messages* buffer for irregularities.

@jgeraerts
Copy link

I also dont get any feedback from tests anymore. I see the response coming in *nrepl-messages* but no errors are highlighted.

(--->
  ns  "net.umask.imageresizer.cache-test"
  op  "test"
  tests  nil  session  "dba28b3c-8ad4-486b-aa2a-694285ddcb34"
  id  "11"
)
(<-
  id  "11"
  ns  "net.umask.imageresizer.cache-test"
  results  (dict
             test-cache  ((dict "actual" "(not (= \"from-handler\" nil))
\n" "context" "we should get a cache miss when something is not present" "expected" "(= \"from-handler\" (handler (request :get \"/foo/bar\")))
\n" "file" "cache-test.clj" "index" 0 "line" 18 "message" nil "ns" "net.umask.imageresizer.cache-test" "type" "fail" "var" "test-cache")
 (dict "actual" "(not (= true false))
\n" "context" "we should get a cache miss when something is not present" "expected" "(= true false)
\n" "file" "cache-test.clj" "index" 1 "line" 19 "message" nil "ns" "net.umask.imageresizer.cache-test" "type" "fail" "var" "test-cache"))
           )
  session  "dba28b3c-8ad4-486b-aa2a-694285ddcb34"
  summary  (dict
             error  0
             fail  2
             pass  0
             test  2
             var  1
           )
)

Might be related as well.

@bbatsov
Copy link
Member

bbatsov commented Nov 30, 2014

I need some minimal repro case for this. So far I've never run into any of the two problems myself.

@jgeraerts
Copy link

wonder what was wrong. I cannot reproduce it anymore. I updated magit and graphviz mode to latest versions of melpa-stable and problem seems to be gone. Can it be there was some kind of odd conflict?

@mrcslws
Copy link

mrcslws commented Dec 2, 2014

I'm stuck hitting the "empty *cider-error* buffer" issue, as well. Has anybody successfully gotten out of this state? I upgraded from 0.7.0 to 0.8.1 and immediately starting hitting this.

Dumb question: I don't have a *nrepl-messages* buffer. I just have *cider-repl [project]*, *nrepl-server [project]*, and a blank *cider-error*. Should there be another one?

@cichli
Copy link
Member

cichli commented Dec 2, 2014

I had the same issue in 0.7.0 but it was fixed by #718 - maybe try cleaning out any .elc files and see if it still occurs? If not, does opening cider-stacktrace.el and evaluating it make a difference?

@mrcslws You need to do the following to enable message logging:

(setq nrepl-log-messages t)

This is probably related to #881 btw. I'll see if I can reproduce this evening.

@ptaoussanis
Copy link

Empty *cider-error* buffer here too with 0.8.1 (CIDER 0.8.1 (Java 1.7.0_04, Clojure 1.7.0, nREPL 0.2.6)). Don't have any *nrepl-messages* buffer.

Does anyone know how to downgrade to 0.7.0 via Elpa? I can't see any of the old packages after upgrading to 0.8.1.

@ptaoussanis
Copy link

Ahh, see here for how to get an *nrepl-messages* buffer. That's got the stacktrace info for me (it's not particularly presentable, but it's there).

@dkincaid
Copy link

dkincaid commented Dec 2, 2014

I'm getting the same empty cider-error buffer as others on 0.8.1.

@bbatsov
Copy link
Member

bbatsov commented Dec 2, 2014

I'm guessing some of you might have some leftovers of previous CIDER versions around. Can't think of another explanation why this problem isn't observed by all users.

@mrcslws
Copy link

mrcslws commented Dec 3, 2014

Actually, I'm finding that I get into this state after printing something large.

Consistent repro steps:

  1. cider-jack-in
  2. (+ 1 nil)
    RESULT: It works. I see a stack trace.
  3. (println (repeat 1000 "hello"))
  4. (+ 1 nil)
    RESULT: It doesn't work. *cider-error* is blank.

*nrepl-messages* for this final command:

(--->
  ns  "user"
  op  "eval"
  session  "cec0a9f9-36ce-47b8-9126-ca257e103a37"
  code  "(+ 1 nil)\n"
  id  "11"
)
(<-
  ex  "class java.lang.NullPointerException"
  id  "11"
  root-ex  "class java.lang.NullPointerException"
  session  "cec0a9f9-36ce-47b8-9126-ca257e103a37"
  status  ("eval-error")
)
(--->
  op  "stacktrace"
  session  "cec0a9f9-36ce-47b8-9126-ca257e103a37"
  print-level  50
  id  "12"
)
(<-
  err  "NullPointerException   [trace missing]\n"
  id  "11"
  session  "cec0a9f9-36ce-47b8-9126-ca257e103a37"
)
(<-
  id  "11"
  session  "cec0a9f9-36ce-47b8-9126-ca257e103a37"
  status  ("done")
)

@ptaoussanis
Copy link

I'm guessing some of you might have some leftovers of previous CIDER versions around.

Hi Bozhidar, appreciate the response. Could you possibly point me to some info for an emacs novice re: how to clear previous versions and I'll let you know if it helps in my case?

Cheers! :-)

@jgeraerts
Copy link

if you installed your previous versions through elpa you find the installations in ~/.emacs.d/elpa. You just remove the directory of old cider versions and restart emacs.

@mrcslws
Copy link

mrcslws commented Dec 3, 2014

FWIW, I deleted the 0.7 package before installing 0.8.1, and I'm seeing this.

@mrcslws
Copy link

mrcslws commented Dec 3, 2014

Yeah, I think this is project-specific, not related to upgrades. I see it with a freshly-cloned https://github.com/nupic-community/comportex but not with other projects that I've tried. I used my repro steps above.

@ptaoussanis
Copy link

Thanks @jgeraerts, I can confirm then that removing the old cider versions did not help in my case. Errors still result in a blank *cider-error* buffer, no change.

Would be happy to run any other tests or gather any other info that might help with diagnosing the cause.

Cheers!

@vspinu
Copy link
Contributor

vspinu commented Dec 3, 2014

@mrcsiws, could you please give more concrete steps of how to reproduce? I have loaded comportex an it seems to work fine. I do see the stacktrace on whatever error I try.

@mrcslws
Copy link

mrcslws commented Dec 3, 2014

Hmm even with my repro steps above? This comment: #895 (comment)

@bbatsov bbatsov added the bug label Dec 5, 2014
@joegallo
Copy link

joegallo commented Dec 5, 2014

I only noticed this after I installed clojure-mode 3.0.1 (that doesn't mean that it only happened after that, but I can only say for certain that I noticed it after that).

Deleting the entire elpa/cider-0.8.1 directory and reinstalling the package solved the problem for me.

@mrcslws
Copy link

mrcslws commented Dec 6, 2014

Deleting cider-0.8.1 doesn't fix it -- starting a fresh session temporarily fixes it until you print something large. And this only repros for certain projects. At least, that's what I'm seeing.

@vspinu
Copy link
Contributor

vspinu commented Dec 6, 2014

Hmm even with my repro steps above? This comment: #895 (comment)

I can reproduce it with comportex and 10000 iterations in println.

@vspinu
Copy link
Contributor

vspinu commented Dec 7, 2014

Jvm optimizes the stacktrace out:

user> (+ 1 nil)
NullPointerException   clojure.lang.Numbers.ops (Numbers.java:961)
user> (println (repeat 10000 "hello"))
...
user> (first (.getStackTrace *e))
nil

More info here.

The solution is to add :jvm-opts ["-XX:-OmitStackTraceInFastThrow"] to your profile.

The only fix on Cider side I can think of is to give a meaningful message on empty stacktrace.

@vspinu
Copy link
Contributor

vspinu commented Dec 7, 2014

lein looks for JVM_OPTS environment var. Thus Cider can check and append this option on statrup.

@ptaoussanis
Copy link

Hi Vitalie, thanks for the suggestion! Unfortunately I can confirm that adding "-XX:-OmitStackTraceInFastThrow" to my :jvm-opts did not resolve the problem.

Still seeing the same empty *cider-error* buffer on errors. Any other ideas? I'm happy to keep trying things out.

Cheers :-)

@vspinu
Copy link
Contributor

vspinu commented Dec 7, 2014

@ptaoussanis, there might be multiple issues with the stacktrace. What does (first (.getStackTrace *e)) say after the error? And what are your relevant *nrepl-messages*?

@ptaoussanis
Copy link

What does (first (.getStackTrace *e)) say after the error?

Returns the StackTrace as expected, #<StackTraceElement[] [Ljava.lang.StackTraceElement;@6520f771>. Inspected the contents and they seem fine to me.

And what are your relevant *nrepl-messages*?

Trying to eval (/ 1 0) with cider-eval-last-sexp gives:

(--->
  op  "load-file"
  session  "4167a083-0285-48f3-8f03-6efb25b219dc"
  file  "(ns taoensso.scratch (:require [taoensso.ns-templates]))\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n(/ 1 0)"
  file-path  "/<elided>/scratch.clj"
  file-name  "scratch.clj"
  id  "33"
)
(<-
  ex  "class clojure.lang.Compiler$CompilerException"
  id  "33"
  root-ex  "class clojure.lang.Compiler$CompilerException"
  session  "4167a083-0285-48f3-8f03-6efb25b219dc"
  status  ("eval-error")
)
(--->
  op  "stacktrace"
  session  "4167a083-0285-48f3-8f03-6efb25b219dc"
  print-level  50
  id  "34"
)
(<-
  err  "CompilerException java.lang.ArithmeticException: Divide by zero, compiling:(/Users/ptaoussanis/Projects/ensso/src/taoensso/scratch.clj:1:57) \n"
  id  "33"
  session  "4167a083-0285-48f3-8f03-6efb25b219dc"
)
(<-
  id  "33"
  session  "4167a083-0285-48f3-8f03-6efb25b219dc"
  status  ("done")
)
(<-
  class  "clojure.lang.Compiler$CompilerException"
  id  "34"
  message  "Error compiling: /Users/ptaoussanis/Projects/ensso/src/taoensso/scratch.clj:1:57"
  session  "4167a083-0285-48f3-8f03-6efb25b219dc"
  stacktrace  ((dict "class" "clojure.lang.Compiler" "file" "Compiler.java" "flags"
       ("java")
       "line" 7207 "method" "load" "name" "clojure.lang.Compiler/load" "type" "java")
 (dict "class" "user$eval50637" "file" "form-init6791495827239051289.clj" "flags"
       ("tooling" "repl" "clj")
       "fn" "eval50637" "line" 1 "method" "invoke" "name" "user$eval50637/invoke" "ns" "user" "type" "clj" "var" "user/eval50637")
 (dict "class" "clojure.lang.Compiler" "file" "Compiler.java" "flags"
       ("tooling" "java")
       "line" 6768 "method" "eval" "name" "clojure.lang.Compiler/eval" "type" "java")
 (dict "class" "clojure.lang.Compiler" "file" "Compiler.java" "flags"
       ("dup" "tooling" "java")
       "line" 6731 "method" "eval" "name" "clojure.lang.Compiler/eval" "type" "java")
 (dict "class" "clojure.core$eval" "file" "core.clj" "flags"
       ("tooling" "clj")
       "fn" "eval" "line" 3076 "method" "invoke" "name" "clojure.core$eval/invoke" "ns" "clojure.core" "type" "clj" "var" "clojure.core/eval")
 (dict "class" "clojure.main$repl$read_eval_print__7020$fn__7023" "file" "main.clj" "flags"
       ("tooling" "clj")
       "fn" "repl/read-eval-print/fn" "line" 239 "method" "invoke" "name" "clojure.main$repl$read_eval_print__7020$fn__7023/invoke" "ns" "clojure.main" "type" "clj" "var" "clojure.main/repl")
 (dict "class" "clojure.main$repl$read_eval_print__7020" "file" "main.clj" "flags"
       ("dup" "tooling" "clj")
       "fn" "repl/read-eval-print" "line" 239 "method" "invoke" "name" "clojure.main$repl$read_eval_print__7020/invoke" "ns" "clojure.main" "type" "clj" "var" "clojure.main/repl")
 (dict "class" "clojure.main$repl$fn__7029" "file" "main.clj" "flags"
       ("tooling" "clj")
       "fn" "repl/fn" "line" 257 "method" "invoke" "name" "clojure.main$repl$fn__7029/invoke" "ns" "clojure.main" "type" "clj" "var" "clojure.main/repl")
 (dict "class" "clojure.main$repl" "file" "main.clj" "flags"
       ("dup" "tooling" "clj")
       "fn" "repl" "line" 257 "method" "doInvoke" "name" "clojure.main$repl/doInvoke" "ns" "clojure.main" "type" "clj" "var" "clojure.main/repl")
 (dict "class" "clojure.lang.RestFn" "file" "RestFn.java" "flags"
       ("tooling" "java")
       "line" 1523 "method" "invoke" "name" "clojure.lang.RestFn/invoke" "type" "java")
 (dict "class" "clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__7272" "file" "interruptible_eval.clj" "flags"
       ("tooling" "clj")
       "fn" "evaluate/fn" "line" 67 "method" "invoke" "name" "clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__7272/invoke" "ns" "clojure.tools.nrepl.middleware.interruptible-eval" "type" "clj" "var" "clojure.tools.nrepl.middleware.interruptible-eval/evaluate")
 (dict "class" "clojure.lang.AFn" "file" "AFn.java" "flags"
       ("tooling" "java")
       "line" 152 "method" "applyToHelper" "name" "clojure.lang.AFn/applyToHelper" "type" "java")
 (dict "class" "clojure.lang.AFn" "file" "AFn.java" "flags"
       ("tooling" "java")
       "line" 144 "method" "applyTo" "name" "clojure.lang.AFn/applyTo" "type" "java")
 (dict "class" "clojure.core$apply" "file" "core.clj" "flags"
       ("tooling" "clj")
       "fn" "apply" "line" 626 "method" "invoke" "name" "clojure.core$apply/invoke" "ns" "clojure.core" "type" "clj" "var" "clojure.core/apply")
 (dict "class" "clojure.core$with_bindings_STAR_" "file" "core.clj" "flags"
       ("tooling" "clj")
       "fn" "with-bindings*" "line" 1864 "method" "doInvoke" "name" "clojure.core$with_bindings_STAR_/doInvoke" "ns" "clojure.core" "type" "clj" "var" "clojure.core/with-bindings*")
 (dict "class" "clojure.lang.RestFn" "file" "RestFn.java" "flags"
       ("tooling" "java")
       "line" 425 "method" "invoke" "name" "clojure.lang.RestFn/invoke" "type" "java")
 (dict "class" "clojure.tools.nrepl.middleware.interruptible_eval$evaluate" "file" "interruptible_eval.clj" "flags"
       ("tooling" "clj")
       "fn" "evaluate" "line" 51 "method" "invoke" "name" "clojure.tools.nrepl.middleware.interruptible_eval$evaluate/invoke" "ns" "clojure.tools.nrepl.middleware.interruptible-eval" "type" "clj" "var" "clojure.tools.nrepl.middleware.interruptible-eval/evaluate")
 (dict "class" "clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__7314$fn__7317" "file" "interruptible_eval.clj" "flags"
       ("tooling" "clj")
       "fn" "interruptible-eval/fn/fn" "line" 183 "method" "invoke" "name" "clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__7314$fn__7317/invoke" "ns" "clojure.tools.nrepl.middleware.interruptible-eval" "type" "clj" "var" "clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval")
 (dict "class" "clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__7307" "file" "interruptible_eval.clj" "flags"
       ("tooling" "clj")
       "fn" "run-next/fn" "line" 152 "method" "invoke" "name" "clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__7307/invoke" "ns" "clojure.tools.nrepl.middleware.interruptible-eval" "type" "clj" "var" "clojure.tools.nrepl.middleware.interruptible-eval/run-next")
 (dict "class" "clojure.lang.AFn" "file" "AFn.java" "flags"
       ("tooling" "java")
       "line" 22 "method" "run" "name" "clojure.lang.AFn/run" "type" "java")
 (dict "class" "java.util.concurrent.ThreadPoolExecutor" "file" "ThreadPoolExecutor.java" "flags"
       ("tooling" "java")
       "line" 1110 "method" "runWorker" "name" "java.util.concurrent.ThreadPoolExecutor/runWorker" "type" "java")
 (dict "class" "java.util.concurrent.ThreadPoolExecutor$Worker" "file" "ThreadPoolExecutor.java" "flags"
       ("tooling" "java")
       "line" 603 "method" "run" "name" "java.util.concurrent.ThreadPoolExecutor$Worker/run" "type" "java")
 (dict "class" "java.lang.Thread" "file" "Thread.java" "flags"
       ("tooling" "java")
       "line" 722 "method" "run" "name" "java.lang.Thread/run" "type" "java"))
)
(<-
  class  "java.lang.ArithmeticException"
  id  "34"
  message  "Divide by zero"
  session  "4167a083-0285-48f3-8f03-6efb25b219dc"
  stacktrace  ((dict "class" "clojure.lang.Numbers" "file" "Numbers.java" "flags"
       ("java")
       "line" 158 "method" "divide" "name" "clojure.lang.Numbers/divide" "type" "java")
 (dict "class" "clojure.lang.Numbers" "file" "Numbers.java" "flags"
       ("dup" "java")
       "line" 3808 "method" "divide" "name" "clojure.lang.Numbers/divide" "type" "java")
 (dict "class" "taoensso.scratch$eval50649" "file" "scratch.clj" "flags"
       ("clj")
       "fn" "eval50649" "line" 97 "method" "invoke" "name" "taoensso.scratch$eval50649/invoke" "ns" "taoensso.scratch" "type" "clj" "var" "taoensso.scratch/eval50649")
 (dict "class" "clojure.lang.Compiler" "file" "Compiler.java" "flags"
       ("tooling" "java")
       "line" 6768 "method" "eval" "name" "clojure.lang.Compiler/eval" "type" "java")
 (dict "class" "clojure.lang.Compiler" "file" "Compiler.java" "flags"
       ("tooling" "java")
       "line" 7195 "method" "load" "name" "clojure.lang.Compiler/load" "type" "java")
 (dict "class" "user$eval50637" "file" "form-init6791495827239051289.clj" "flags"
       ("tooling" "repl" "clj")
       "fn" "eval50637" "line" 1 "method" "invoke" "name" "user$eval50637/invoke" "ns" "user" "type" "clj" "var" "user/eval50637")
 (dict "class" "clojure.lang.Compiler" "file" "Compiler.java" "flags"
       ("tooling" "java")
       "line" 6768 "method" "eval" "name" "clojure.lang.Compiler/eval" "type" "java")
 (dict "class" "clojure.lang.Compiler" "file" "Compiler.java" "flags"
       ("dup" "tooling" "java")
       "line" 6731 "method" "eval" "name" "clojure.lang.Compiler/eval" "type" "java")
 (dict "class" "clojure.core$eval" "file" "core.clj" "flags"
       ("tooling" "clj")
       "fn" "eval" "line" 3076 "method" "invoke" "name" "clojure.core$eval/invoke" "ns" "clojure.core" "type" "clj" "var" "clojure.core/eval")
 (dict "class" "clojure.main$repl$read_eval_print__7020$fn__7023" "file" "main.clj" "flags"
       ("tooling" "clj")
       "fn" "repl/read-eval-print/fn" "line" 239 "method" "invoke" "name" "clojure.main$repl$read_eval_print__7020$fn__7023/invoke" "ns" "clojure.main" "type" "clj" "var" "clojure.main/repl")
 (dict "class" "clojure.main$repl$read_eval_print__7020" "file" "main.clj" "flags"
       ("dup" "tooling" "clj")
       "fn" "repl/read-eval-print" "line" 239 "method" "invoke" "name" "clojure.main$repl$read_eval_print__7020/invoke" "ns" "clojure.main" "type" "clj" "var" "clojure.main/repl")
 (dict "class" "clojure.main$repl$fn__7029" "file" "main.clj" "flags"
       ("tooling" "clj")
       "fn" "repl/fn" "line" 257 "method" "invoke" "name" "clojure.main$repl$fn__7029/invoke" "ns" "clojure.main" "type" "clj" "var" "clojure.main/repl")
 (dict "class" "clojure.main$repl" "file" "main.clj" "flags"
       ("dup" "tooling" "clj")
       "fn" "repl" "line" 257 "method" "doInvoke" "name" "clojure.main$repl/doInvoke" "ns" "clojure.main" "type" "clj" "var" "clojure.main/repl")
 (dict "class" "clojure.lang.RestFn" "file" "RestFn.java" "flags"
       ("tooling" "java")
       "line" 1523 "method" "invoke" "name" "clojure.lang.RestFn/invoke" "type" "java")
 (dict "class" "clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__7272" "file" "interruptible_eval.clj" "flags"
       ("tooling" "clj")
       "fn" "evaluate/fn" "line" 67 "method" "invoke" "name" "clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__7272/invoke" "ns" "clojure.tools.nrepl.middleware.interruptible-eval" "type" "clj" "var" "clojure.tools.nrepl.middleware.interruptible-eval/evaluate")
 (dict "class" "clojure.lang.AFn" "file" "AFn.java" "flags"
       ("tooling" "java")
       "line" 152 "method" "applyToHelper" "name" "clojure.lang.AFn/applyToHelper" "type" "java")
 (dict "class" "clojure.lang.AFn" "file" "AFn.java" "flags"
       ("tooling" "java")
       "line" 144 "method" "applyTo" "name" "clojure.lang.AFn/applyTo" "type" "java")
 (dict "class" "clojure.core$apply" "file" "core.clj" "flags"
       ("tooling" "clj")
       "fn" "apply" "line" 626 "method" "invoke" "name" "clojure.core$apply/invoke" "ns" "clojure.core" "type" "clj" "var" "clojure.core/apply")
 (dict "class" "clojure.core$with_bindings_STAR_" "file" "core.clj" "flags"
       ("tooling" "clj")
       "fn" "with-bindings*" "line" 1864 "method" "doInvoke" "name" "clojure.core$with_bindings_STAR_/doInvoke" "ns" "clojure.core" "type" "clj" "var" "clojure.core/with-bindings*")
 (dict "class" "clojure.lang.RestFn" "file" "RestFn.java" "flags"
       ("tooling" "java")
       "line" 425 "method" "invoke" "name" "clojure.lang.RestFn/invoke" "type" "java")
 (dict "class" "clojure.tools.nrepl.middleware.interruptible_eval$evaluate" "file" "interruptible_eval.clj" "flags"
       ("tooling" "clj")
       "fn" "evaluate" "line" 51 "method" "invoke" "name" "clojure.tools.nrepl.middleware.interruptible_eval$evaluate/invoke" "ns" "clojure.tools.nrepl.middleware.interruptible-eval" "type" "clj" "var" "clojure.tools.nrepl.middleware.interruptible-eval/evaluate")
 (dict "class" "clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__7314$fn__7317" "file" "interruptible_eval.clj" "flags"
       ("tooling" "clj")
       "fn" "interruptible-eval/fn/fn" "line" 183 "method" "invoke" "name" "clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__7314$fn__7317/invoke" "ns" "clojure.tools.nrepl.middleware.interruptible-eval" "type" "clj" "var" "clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval")
 (dict "class" "clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__7307" "file" "interruptible_eval.clj" "flags"
       ("tooling" "clj")
       "fn" "run-next/fn" "line" 152 "method" "invoke" "name" "clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__7307/invoke" "ns" "clojure.tools.nrepl.middleware.interruptible-eval" "type" "clj" "var" "clojure.tools.nrepl.middleware.interruptible-eval/run-next")
 (dict "class" "clojure.lang.AFn" "file" "AFn.java" "flags"
       ("tooling" "java")
       "line" 22 "method" "run" "name" "clojure.lang.AFn/run" "type" "java")
 (dict "class" "java.util.concurrent.ThreadPoolExecutor" "file" "ThreadPoolExecutor.java" "flags"
       ("tooling" "java")
       "line" 1110 "method" "runWorker" "name" "java.util.concurrent.ThreadPoolExecutor/runWorker" "type" "java")
 (dict "class" "java.util.concurrent.ThreadPoolExecutor$Worker" "file" "ThreadPoolExecutor.java" "flags"
       ("tooling" "java")
       "line" 603 "method" "run" "name" "java.util.concurrent.ThreadPoolExecutor$Worker/run" "type" "java")
 (dict "class" "java.lang.Thread" "file" "Thread.java" "flags"
       ("tooling" "java")
       "line" 722 "method" "run" "name" "java.lang.Thread/run" "type" "java"))
)
(<-
  id  "34"
  session  "4167a083-0285-48f3-8f03-6efb25b219dc"
  status  ("done")
)

@vspinu
Copy link
Contributor

vspinu commented Dec 7, 2014

@ptaoussanis, your problem is on elisp side and is different from what @mrcslws has reported. You are receiving the stacktrace but something happens during the rendering. Do you see any elisp erros in your *messages* buffer. If so, could you please provide the stacktrace (M-x toggle-debug-on-error).

@mrcslws, does the :jvm-opts solution fix your problem?

@dkincaid
Copy link

dkincaid commented Dec 7, 2014

I am having the exact same experience as @ptaoussanis. I'm not getting any elisp errors in Messages buffer.

@vspinu
Copy link
Contributor

vspinu commented Dec 7, 2014

I am having the exact same experience as @ptaoussanis. I'm not getting any elisp errors in Messages buffer.

I am having exactly the same messages as @ptaoussanis posted and everything works as expected. I am afraid you will have to try to debug it yourself. C-h f cider-stacktrace-render-frame and go to its source. Check that it's indeed in the directory of the latest Cider. Edebug it with C-u C-M-x. Then step through the code when next Clojure error and see if it prints the error frames into the right buffer. Play with other relevant functions cider-stacktrace-render-cause and cider-stacktrace-render till you figure out what's going on.

Unfortunately edebug doesn't enter into nrepl-dbind-response macro for unclear reason, but you might be able to figure it out as it is.

@dkincaid
Copy link

dkincaid commented Dec 7, 2014

I know very little about elisp or how to debug it. I'm happy to help try to troubleshoot this as much as I can. I was able to check that cider-stacktrace-render-frame is in cider-stacktrace.el which is in the cider-0.8.1 directory (and nowhere else). C-u C-M-x inside the *cider-repl* buffer gives the following error:

Debugger entered--Lisp error: (error "No Lisp subprocess; see variable `inferior-lisp-buffer'")
  signal(error ("No Lisp subprocess; see variable `inferior-lisp-buffer'"))
  error("No Lisp subprocess; see variable `inferior-lisp-buffer'")
  inferior-lisp-proc()
  lisp-eval-region(202 297)
  lisp-do-defun(lisp-eval-string lisp-eval-region)
  lisp-eval-defun((4))
  call-interactively(lisp-eval-defun nil nil)

@vspinu
Copy link
Contributor

vspinu commented Dec 7, 2014

:-). C-u C-M-x should be called on the source of cider-stacktrace-render-frame. When the debugger starts, step with n.

@bbatsov
Copy link
Member

bbatsov commented Dec 7, 2014

I know very little about elisp or how to debug it. I'm happy to help try to troubleshoot this as much as I can. I was able to check that cider-stacktrace-render-frame is in cider-stacktrace.el which is in the cider-0.8.1 directory (and nowhere else). C-u C-M-x inside the cider-repl buffer gives the following error:

Seems to me you're actually running some command from inferior-lisp-mode for some reason.

@dkincaid
Copy link

dkincaid commented Dec 7, 2014

Ok. I must be doing something wrong. I have cider-stacktrace.el open in a buffer and did C-u C-M-x inside the cider-stacktrace-render-frame function. I get the message Edebug: cider-stacktrace-render-frame in the mini-buffer. Then I run (/ 1 0) in the cider-repl buffer and nothing different happens. It doesn't seem to enter the debugger at all.

@vspinu
Copy link
Contributor

vspinu commented Dec 8, 2014

It doesn't seem to enter the debugger at all.

Ok. We are getting somewhere then. Try to debug cider-stacktrace-render. This is the entry point from cider-interaction. it could be that cider-stacktrace is not triggered in the first place, but I don't see any reason for that.

@dkincaid
Copy link

dkincaid commented Dec 8, 2014

Sorry. I should have mentioned that I tried the edebug thing in the other two functions you mentioned - cider-stacktrace-render and cider-stacktrace-render-cause as well. Same thing happened. It never went into debug.

@ptaoussanis
Copy link

@ptaoussanis, your problem is on elisp side and is different from what @mrcslws has reported. You are receiving the stacktrace but something happens during the rendering. Do you see any elisp erros in your messages buffer. If so, could you please provide the stacktrace (M-x toggle-debug-on-error).

Ran (M-x toggle-debug-on-error) and got "Debug on Error enabled globally" in the *Messages* buffer.

Then eval (/ 1 0) in the *cider-repl* buffer and get the usual result:

  1. Exception prints in *cider-repl*.
  2. An empty *cider-error* pops up and takes focus.

There is no new content in *Messages*.


C-h f cider-stacktrace-render-frame and go to its source. Check that it's indeed in the directory of the latest Cider.

Confirmed, it's the same version (~/emacs.d/elpa/cider-0.8.1/cider-stacktrace.el).

Edebug it with C-u C-M-x.
Done.

Then step through the code when next Clojure error and see if it prints the error frames into the right buffer.

Eval (/ 1 0) in *cider-repl* doesn't seem to trigger cider-stracktrace-render-frame at all.

Play with other relevant functions cider-stacktrace-render-cause and cider-stacktrace-render till you figure out what's going on.

Tried edebug on and tried modifying cider-stracktrace-render-cause, cider-stacktrace-render, and a couple other funs - couldn't get any change in behaviour.

Am either doing something wrong, or none of the these functions is ever being called?

I've never done elisp development. To confirm: if I replace the whole cider-stacktrace-render with:

(defun cider-stacktrace-render (buffer causes)
  "Emit into BUFFER useful stacktrace information for the CAUSES."
  (debug))

Then call eval-defun on that, we're expecting something different to happen when I eval (/ 1 0) in the *cider-repl*, right? Nothing different is happening; does that imply that cider-stacktrace-render is never actually running?

@ptaoussanis
Copy link

Hold up, I think I got it working - will update once I've confirmed the solution.

@ptaoussanis
Copy link

Okay, when I eval (/ 1 0) in *cider-repl* I now get *cider-error* popping up with the expectd interactive stacktrace.

What it took in my case was manually removing [/moving] my entire ~/emacs.d/elpa dir - and just reinstalling everything again with package-list-packages.

I'd previously tried to delete + reinstall just cider-0.8.1 with no success - but reinstalling everything seems to have done the trick.

I was hoping to swap in the old dir and start reinstalling one-by-one to try and pinpoint the actual package(s) that needed reinstalling - but it seems I can't reproduce the error now. I'm not sure if emacs is caching this stuff somewhere?

In any case, this did help in my case - and does seem to point at the behaviour being some sort of an installation cruft/cache problem.

One (unrelated?) oddity: when I eval an error form in a Clojure namespace (let's say (/ 1 0) again) - it brings my cursor back to the top of that namespace. Is there any way I can get it to leave the cursor position alone? Happy to open a separate issue if it's unrelated.

Much thanks for all the assistance on this - and for your work on Cider generally. Really appreciate it.

Cheers! :-)

@bbatsov
Copy link
Member

bbatsov commented Dec 8, 2014

One (unrelated?) oddity: when I eval an error form in a Clojure namespace (let's say (/ 1 0) again) - it brings my cursor back to the top of that namespace. Is there any way I can get it to leave the cursor position alone? Happy to open a separate issue if it's unrelated.

This is the Clojure bug mentioned in this very ticket (+ CIDER's auto-jump-to-error).

@ptaoussanis
Copy link

This is the Clojure bug mentioned in this very ticket (+ CIDER's auto-jump-to-error).

Sorry, to confirm: the cursor jumping to the top of the ns is related to http://dev.clojure.org/jira/browse/CLJ-1568?

So CIDER is jumping to the reported [incorrect] line number? I'll vote for the issue, but any suggested workarounds in the meantime? Perhaps just disabling the jump entirely?

@vspinu
Copy link
Contributor

vspinu commented Dec 8, 2014

In any case, this did help in my case - and does seem to point at the behaviour being some sort of an installation cruft/cache problem.

Yes. Most commonly it's that Emacs loads some older compiled .elc files. These issues are notoriously difficult to debug for non-elispers.

So CIDER is jumping to the reported [incorrect] line number? I'll vote for the issue, but any suggested workarounds in the meantime? Perhaps just disabling the jump entirely?

Clojure 1.5.1 works fine. I have been planing for an improvement to Cider's error navigation (dissucussed in #851) which will fix this issue by side effect.

@bbatsov, can you reopen #851? Github auto-closed it when #866 was merged.

@ptaoussanis
Copy link

@vspinu

Fantastic, thank you! In the meantime, assuming a Clojure version downgrade is infeasible - is there any CIDER code I can mod to just disable the auto jumps for now? I see in #851 that your PR originally had some changes for this - but the commits aren't showing up under #851 any more.

EDIT: Have just disabled the cider-jump-to call in cider-interaction.el's cider-handle-compilation-errors and it seems to be doing the trick for now.

@vspinu
Copy link
Contributor

vspinu commented Dec 9, 2014

is there any CIDER code I can mod to just disable the auto jumps for now?

Customize cider-auto-jump-to-error.

@bbatsov
Copy link
Member

bbatsov commented Dec 9, 2014

@vspinu Fire up a new PR as #851 seems to be messed up. Still, I'm not sure what we can do about this, as I don't recall any real solution for this problem in the PR.

@pbostrom
Copy link
Author

I installed 0.8.2 from melpa stable and the problem went away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants