clojure-emacs / cider

The Clojure Interactive Development Environment that Rocks for Emacs
https://cider.mx
GNU General Public License v3.0
3.54k stars 646 forks source link

cider 0.8.1 does not accurately display errors #895

Closed pbostrom closed 9 years ago

pbostrom commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

bbatsov commented 9 years ago

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

jgeraerts commented 9 years ago

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 commented 9 years ago

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

jgeraerts commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

bbatsov commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

mrcslws commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

Hmm even with my repro steps above? This comment: https://github.com/clojure-emacs/cider/issues/895#issuecomment-65332068

joegallo commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

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

vspinu commented 9 years ago

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 commented 9 years ago

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

ptaoussanis commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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

vspinu commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

bbatsov commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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

ptaoussanis commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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

Customize cider-auto-jump-to-error.

bbatsov commented 9 years ago

@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 commented 9 years ago

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