Errors in *Messages* buffer on cider-jack-in

[kostafey]

CIDER 20140524.138
On cider-jack-in, *Messages* buffer tail:
Error: (error "Cannot decode object: 1")
Error: (wrong-type-argument integer-or-marker-p nil)

[bbatsov]

But everything works regardless of these messages, right?

[turbopape]

Same here. And yes, everything works despite the messages.

2014-05-27 12:01 GMT+01:00 Bozhidar Batsov [email protected]:

But everything works regardless of these messages, right?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/583#issuecomment-44260873
.

[bbatsov]

That's expected. It's the result of a change I made in 5e1d5e3 to be able to spot problems like those.

[kostafey]

Yes, everything works well.

[bbatsov]

There were many errors were silently discarded, which made finding and fixing them pretty hard, therefore this change. At some point we'll weed out the causes of these messages.

[otfrom]

I'm seeing the same as well, but it doesn't appear to stop me working.

[bbatsov]

Seems that something is wrong with the welcome message (the Clojure version contains raw numbers instead of strings in the response message, which might be problematic), but I'm not able to pin-point it yet. Any help debugging this would be welcome!

/cc @gtrak @jeffvalk @hugoduncan

[aamedina]

I'm not certain, but I think this might be related to freezing issues when a stacktrace is rendered by CIDER, where a recursive loop of integer decoding errors causes Emacs to freeze until the process is quit. Has anyone else run into this? I can reproduce it consistently by type checking a namespace (which I know will fail) with core.typed. Reverting to a version of CIDER prior to these commits seems to handle the issue, and of course disabling stacktraces "fixes" it.

[bbatsov]

@aamedina Are the integers in question stacktrace line numbers? //cc @jeffvalk

[aamedina]

I am not sure, because Emacs totally freezes (it keeps printing Error: (wrong-type-argument integer-or-marker-p nil) over and over again until you quit CIDER.)

Do you know of a way to log the stacktrace?

[jeffvalk]

@aamedina Could you try enabling nREPL event logging with(setq nrepl-log-events t), and check the *nrepl-events* buffer for the last op and the messages that follow?

[arrdem]

I'll chime in here as affected by this issue, no debugging information to add unfortunately.

[jeffvalk]

Looks like that variable and buffer just got renamed... Try setting (setq nrepl-log-messages t), and check the *nrepl-messages* buffer.

[bbatsov]

A small update from me. The problem is that on REPL start the current code tries to decode the banner message:

; CIDER 0.7.0snapshot (package: 20140524.138) (Java 1.7.0_17, Clojure 10, nREPL 0.2.3)
user> 

One simple workaround would be to skip it, but I'll try do devise a more robust fix.

[bbatsov]

It seems that some marker is not properly set when the REPL is created, which is causing this, but I still cannot determine which one. It's not clear at all to me why is the initial state of REPL passed to the connection buffer to be decoded...

[bbatsov]

Hmmm, it seems I was incorrect. Actually the problem seems to be here:

(defun nrepl-net-decode ()
  "Decode the data in the current buffer.
Remove the processed data from the buffer if the decode successful."
  (let* ((start (point-min))
         (end (point-max))
         (data (buffer-substring start end)))
    (prog1
        (nrepl-decode data)
      (delete-region start end))))

This function is supposed to be called with the current connection buffer as the current buffer, but when the REPL buffer is created for some reason it temporarily becomes the current buffer and we end up trying to decode its content. I noticed this after spending some quality time debugging a dozen of related functions. I wasted a lot of time today, so I'm giving up for now.

[jeffvalk]

#583, #586, and #597 all look to be related, if not the same issue.