Troubleshooting

In case you run into issues here are a few tips that can help you diagnose the problem.

Generally, it’s not a bad idea to configure Emacs to spit the backtrace on error (instead of just logging the error in the *Messages* buffer). You can toggle this behavior by using M-x toggle-debug-on-error.

Debugging CIDER commands

Emacs features a super powerful built-in Emacs Lisp debugger and using it is the best way to diagnose problems of any kind.

Here’s a great crash course on using the debugger.

To debug some command you need to do the following:

  • Figure out the name of the command you want to debug (e.g. by using C-h k to see which command is associated with some keybinding).

  • Find the source of the command (e.g. by using M-x find-function RET function-name).

  • Press C-u C-M-x while in the body of the function

  • Run the command again.

At this point you’ll be dropped in the debugger and you can step forward until you find the problem.

Profiling CIDER commands

Emacs comes with a built-in profiler. Using it is pretty simple:

  1. Start it with M-x profiler-start.

  2. Invoke some commands.

  3. Get the report with M-x profiler-report.

If you intend to share the profiling results with someone it’s a good idea to save the report buffer to a file with C-x C-w.

Debugging the communication with nREPL

From time to time it might be a good idea to inspect the messages exchanged between CIDER and nREPL. CIDER has a simple message log that looks like this:

(-->
  id         "16"
  op         "eval"
  session    "eb3ef563-86ec-4d9e-9fa8-a56ce0e0f0b0"
  time-stamp "2020-03-15 16:01:42.963936000"
  code       "(in-ns 'nrepl.completion)"
)
(<--
  id         "16"
  session    "eb3ef563-86ec-4d9e-9fa8-a56ce0e0f0b0"
  time-stamp "2020-03-15 16:01:43.027347000"
  ns         "nrepl.completion"
  value      "#namespace[nrepl.completion]"
)
(<--
  id         "16"
  session    "eb3ef563-86ec-4d9e-9fa8-a56ce0e0f0b0"
  time-stamp "2020-03-15 16:01:43.195358000"
  status     ("done")
)

That’s CIDER’s way of representing the request (marked with -->) and response maps (marked with <--).

nREPL message logging is not enabled by default. Set nrepl-log-messages to t to activate it. Alternatively you can use M-x nrepl-toggle-message-logging to enable/disable logging temporary within your current Emacs session. Note that enabling message logging can impact performance.

You can find the message log in the *nrepl-messages repl-info* buffer, provided you’ve enabled nREPL message logging. There’s going to be one buffer per each active REPL.

You can jump quickly to the relevant messages buffer by pressing C-c M-s m.

Commonly encountered problems (and how to solve them)

REPL not starting

Make sure that your CIDER version matches your cider-nrepl version. Check the contents of the *Messages* buffer for CIDER-related errors. You should also check the nREPL messages passed between CIDER and nREPL in *nrepl-messages*. If you don’t see anything useful there it’s time to bring out the big guns.

Debugging the REPL init

To debug CIDER’s REPL initialization it’s a good idea to hook into one of its entry points. Add a breakpoint to cider-make-repl (C-u C-M-x, while in its body). Next time you start CIDER you’ll be dropped in the debugger and you can step forward until you find the problem.

Missing *nrepl-messages* buffer

nREPL message logging is not enabled by default. Set nrepl-log-messages to t to activate it. Alternatively you can use M-x nrepl-toggle-message-logging to enable/disable logging temporary within your current Emacs session. Note that enabling message logging can impact performance.

cider-debug complains that it “failed to instrument …​”

In the REPL buffer, issue the following.

your.namespace> (ns cider.nrepl.middleware.util.instrument)
cider.nrepl.middleware.util.instrument> (def verbose-debug true)

This will cause CIDER to print extensive information to the REPL buffer when you try to debug an expression (e.g., with C-u C-M-x). File an issue and copy this information.

The REPL blows up when some function returns an URL

Most likely you’ve encountered some issue with the content-type middleware. Generally, that’s easy to confirm by inspecting the stracktrace:

user> (java.net.URI. "mailto:foo@bar.com")
#object[java.net.URI 0x36966ca2 "mailto:foo@bar.com"]ERROR: Unhandled REPL handler exception processing message {:op slurp, :url mailto:foo@bar.com, :session 69c4d8e1-7bb4-45ad-8075-d21995fd50ab, :id 1579}
java.net.UnknownServiceException: protocol doesn't support input
	at java.base/java.net.URLConnection.getInputStream(URLConnection.java:840)
	at cider.nrepl.middleware.slurp$slurp_url_to_content_PLUS_body.invokeStatic(slurp.clj:100)
	at cider.nrepl.middleware.slurp$slurp_url_to_content_PLUS_body.invoke(slurp.clj:82)
	at cider.nrepl.middleware.slurp$handle_slurp.invokeStatic(slurp.clj:117)
	at cider.nrepl.middleware.slurp$handle_slurp.invoke(slurp.clj:109)

You can disable the middleware like this:

(setq cider-repl-use-content-types t)

It’s disabled by default starting with CIDER 0.25.

Debugging freezes & lock-ups

Sometimes a CIDER command might hang for a while (e.g. due to a bug or a configuration issue). Such problems are super annoying, but are relatively easy to debug. Here are a few steps you can take in such situations:

  • Do M-x toggle-debug-on-quit

  • Reproduce the problem

  • Hit C-g around 10 seconds into the hang

This will bring up a backtrace with the entire function stack, including function arguments. So you should be able to figure out what’s going on (or at least what’s being required).

Warning saying you have to use newer nREPL

CIDER currently requires at least nREPL 0.6 to work properly. As nREPL comes bundled with Leiningen and Boot, from time to time you might have to override the version supplied by them (e.g. if you’re forced to use an older version of Leiningen or there’s no release bundling the required nREPL version yet). Leiningen users can add this to their profiles.clj to force the proper dependency:

{:repl {:dependencies [[nrepl/nrepl "x.y.z"]]}}

The procedure is pretty similar for Boot.

Make sure you add the newer nREPL dependency to the :dependencies key instead of :plugins (where the cider-nrepl Lein plugin resides). That’s a pretty common mistake.

Generally you’re advised to use the newest nREPL with CIDER, as bugs get fixed in pretty much every release.

Missing clojure-…​ function after CIDER update

Most likely you’ve updated CIDER, without updating clojure-mode as well.

CIDER depends on clojure-mode and you should always update them together, as the latest CIDER version might depend on functionality present only in the latest clojure-mode version.

I upgraded CIDER using package.el and it broke

The built-in package manager isn’t perfect and sometimes it messes up. If you just updated and encountered an error you should try the following before opening an issue: Go into the .emacs.d/elpa directory, delete any folders related to CIDER, restart Emacs and then re-install the missing packages. Note that the order here matters.

I upgraded CIDER using package.el and nothing changed

Emacs doesn’t load the new files, it only installs them on disk. To see the effect of changes you have to restart Emacs.

CIDER complains of the cider-nrepl version

This is a warning displayed on the REPL buffer when it starts, and usually looks like this:

WARNING: CIDER 0.18.0 requires cider-nrepl x.y.z, but you’re currently using cider-nrepl a.b.c. Some functionality may not work properly!

where a.b.c might be an actual version, like 0.17.0, or it might be not installed or nil. The solution to this depends on what you see and on what you’re doing.

You see a number like X.X.X, and you’re starting the REPL with cider-connect

Your project specifies the wrong version for the cider-nrepl middleware. See the instructions in the "Middleware Setup" section.

You see not installed or nil, and you’re starting the REPL with cider-connect

To use cider-connect you need to add the cider-nrepl middleware to your project. See the instructions in the "Middleware Setup" section.

You see not installed or nil, and you’re starting the REPL with cider-jack-in

  • Do C-h v cider-inject-dependencies-at-jack-in, and check that this variable is non-nil.

  • Make sure your project depends on at least Clojure 1.7.0.

  • If you use Leiningen, make sure your lein --version is at least 2.9.0.

  • If you use Boot and you’ve changed cider-boot-parameters, that’s probably the cause.

If the above doesn’t work, you can try specifying the cider-nrepl middleware manually, as per the instructions in the "Middleware Setup" section.

You see a number like X.X.X, and you’re starting the REPL with cider-jack-in

This means you’re manually adding the cider-nrepl middleware in your project, but you shouldn’t do that because cider-jack-in already does that for you. Look into the following files, and ensure you’ve removed all references to cider-nrepl and nrepl: project.clj, build.boot, ~/.lein/profiles.clj and ~/.boot/profile.boot.

The package clj-refactor would normally inject its own middleware on cider-jack-in, just as CIDER itself would. Usually that’s not a problem, as long as you’re using compatible versions of CIDER and clj-refactor, but if you’re getting some error probably that’s not the case. You’ve got two options to solve this:

  • Use compatible versions of the two projects (e.g. their most recent snapshots or most recent stable releases)

  • Disable the clj-refactor middleware injection:

(setq cljr-inject-dependencies-at-jack-in nil)

Off-by-one column numbers

Emacs and Clojure differ in their indexing of column numbers — Emacs starts counting from 0 while Clojure starts from 1. Accordingly, the cider-nrepl middleware uses 1-based indexing and all conversions to 0-based indexing should be handled client-side. See https://github.com/clojure-emacs/cider/issues/2852.

Empty Java stacktraces

Occasionally the JVM might remove some stack frames, resulting in no stacktrace information being displayed in CIDER’s error buffer.

That’s caused by an JVM optimization (OmitStackTraceInFastThrow, enabled by default), which optimizes "built-in" exceptions that are thrown frequently enough to be cached and have no stacktrace.

You can turn off the optimization by adding the JVM flag -XX:-OmitStackTraceInFastThrow to whatever command you’re using to start nREPL.

In particular, by adding it to a deps.edn file under an alias (eg. :dev)

---
{:aliases
 {:dev
  {:jvm-opts ["-XX:-OmitStackTraceInFastThrow"]
  ...}}}
---

Or by customising the jack-in options.

---
(setq cider-clojure-cli-global-options "-J-XX:-OmitStackTraceInFastThrow")
---
Leiningen disables OmitStackTraceInFastThrow by default.

If you get any errors related to enrich-classpath when doing cider-jack-in, you can disable the enrich-classpath integration like this:

(setq cider-enrich-classpath nil)

Firstly, make sure that you are using enrich-classpath. cider-enrich-classpath should be truthy. If you are launching your own repl process, it should have the enrich-classpath Leiningen plugin or clojure wrapper.

If you are on Linux and still can’t navigate to the source of built-in methods like .toUpperCase you probably haven’t installed the JDK sources. While you’re at it - it’s good to install the JDK’s Javadocs as well. On Debian/Ubuntu:

$ sudo apt install openjdk-17-source openjdk-17-doc

On Red Hat/Fedora/CentOS:

$ sudo dnf install java-17-openjdk-src java-17-openjdk-javadoc

On Guix:

$ guix package -i openjdk:jdk
On Windows and macOS the JDK source code is bundled with the JDK.

Pressing RET in the REPL does not evaluate forms

Are you a Paredit user? Have you enabled for the REPL buffers?

In recent versions of Paredit (25+), RET is bound to paredit-RET. This can cause unexpected behaviour in the repl when paredit-mode is enabled, e.g. it appears to hang after hitting RET instead of evaluating the last form.

You can disable this Paredit behaviour by adding the following to your init.el:

(define-key paredit-mode-map (kbd "RET") nil)