cider

2024-12-13T21:18:51.686449Z

I'm doing some FFI and crashing my JVM, but I can't seem to find a way to read the crash info when I've launched via cider-jack-in. I just get a "Closed on ..." string in my repl. Is there a way to view the stdout / stderr of the JVM launched by cider?

2024-12-13T21:21:04.029369Z

I know there's output, because if I run the command used by jack-in on a terminal and use that repl, I see it:

22:12:05 $ /opt/local/bin/clojure -Sdeps \{\:deps\ \{nrepl/nrepl\ \{\:mvn/version\ \"1.3.0\"\}\ cider/cider-nrepl\ \{\:mvn/version\ \"0.50.2\"\}\}\ \:aliases\ \{\:cider/nrepl\ \{\:main-opts\ \[\"-m\"\ \"nrepl.cmdline\"\ \"--middleware\"\ \"\[cider.nrepl/cider-middleware\]\"\]\}\}\} -Adev  -M:cider/nrepl 
nREPL server started on port 57075 on host localhost - 
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', ...

2024-12-13T21:22:48.458249Z

I could have sworn there used to be a *cider backend* buffer or something which had this kind of thing in it.

dpsutton 2024-12-13T22:12:06.091889Z

not really on point, but i would copy the startup command (`C-u m-x cider-jac-in` and copy if from the minibuffer) and then launch the process outside of emacs and cider-connect for exactly this reason. Emacs is running the process and getting in the way. Remove the middleman and you have a regular jvm and you can easily poke it

oyakushev 2024-12-13T22:26:16.334089Z

When the JVM crashes, it creates this hs_something file in the root directory of the project. You should check there.

1
2024-12-14T09:37:17.016329Z

Is there a flag required for that file? It didn't happen on my machine (Mac) with the temurin 23 jdk. Though I had an actual JVM crash, not an out of memory error and corresponding heapdump.

oyakushev 2024-12-14T10:49:17.179519Z

1. I've never changed any flags for that, so I believe it should be by default. 2. To get a heapdump on OOM you actually need to set a flag. But hs_ file is not a heapdump, it only shows a native stacktrace and some register state and a few other things. I was under the impression that it would be written always on JVM crashes. 3. Regular OOM should not force-exit the process, it is only raised in one thread that did the allocation that triggered the OOM, the process would survive. Anyway, looks like @dpsutton's advice is your best bet then. Run the REPl process in a separate terminal, and you'll hopefully see it's deathrattle there.

2024-12-14T13:46:41.583399Z

Oh yeah, sorry if I wasn't clear about that -- I already tried that (it's what my original code snippet above does). I'm just asking in case there's a cider setting or something I can set to use instead. Would be much nicer to be able to use cider-jack-in consistently across all my projects.

oyakushev 2024-12-14T14:06:43.209479Z

Looking at CIDER source code, it appears that any process shutdown results in *nrepl-server* buffer being killed unconditionally. This is where you would see the error message if it wouldn't. But there is currently no option to prevent the buffer from closing. I would consider adding such an option because it would be useful to me too. What do you think, @bozhidar?

bozhidar 2024-12-14T14:33:17.248079Z

Yeah, that's fine. I think it can be even a bit broader - like a list of CIDER buffers we want to keep after killing CIDER. (`nil` by default)

bozhidar 2024-12-14T14:35:28.749129Z

(if I recall correctly we track down all such buffers via cider-ancillary-buffers, so I simple hack would be to modify it manually before we release a proper way to preserve some buffers)