Closed pbostrom closed 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.
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.
I can't reproduce the problem with the missing stacktrace buffer.
You can check your *nrepl-messages*
buffer for irregularities.
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.
I need some minimal repro case for this. So far I've never run into any of the two problems myself.
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?
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?
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.
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
.
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).
I'm getting the same empty cider-error buffer as others on 0.8.1.
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.
Actually, I'm finding that I get into this state after printing something large.
Consistent repro steps:
cider-jack-in
(+ 1 nil)
RESULT: It works. I see a stack trace.(println (repeat 1000 "hello"))
(+ 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")
)
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! :-)
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.
FWIW, I deleted the 0.7 package before installing 0.8.1, and I'm seeing this.
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.
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!
@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.
Hmm even with my repro steps above? This comment: https://github.com/clojure-emacs/cider/issues/895#issuecomment-65332068
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.
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.
Hmm even with my repro steps above? This comment: #895 (comment)
I can reproduce it with comportex
and 10000 iterations in println
.
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.
lein looks for JVM_OPTS
environment var. Thus Cider can check and append this option on statrup.
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 :-)
@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*
?
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")
)
@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?
I am having the exact same experience as @ptaoussanis. I'm not getting any elisp errors in Messages buffer.
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.
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)
:-). C-u C-M-x
should be called on the source of cider-stacktrace-render-frame
. When the debugger starts, step with n
.
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.
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.
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.
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, 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:
*cider-repl*
.*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?
Hold up, I think I got it working - will update once I've confirmed the solution.
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! :-)
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).
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?
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.
@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.
is there any CIDER code I can mod to just disable the auto jumps for now?
Customize cider-auto-jump-to-error
.
@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.
I installed 0.8.2 from melpa stable and the problem went away.
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:
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 expressionC-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.