Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

java.lang.NoClassDefFoundError: Could not initialize class #273

Closed
mjmeintjes opened this issue May 6, 2018 · 33 comments
Closed

java.lang.NoClassDefFoundError: Could not initialize class #273

mjmeintjes opened this issue May 6, 2018 · 33 comments

Comments

@mjmeintjes
Copy link

Shadow-cljs version 2.3.19

What happens:
I'm getting the following error when I recompile and there is some syntax error in my code. The compiling also seems to not finish when this happens.

I can provide more information if you let me know what you need.

[2018-05-06 17:13:03 - WARNING] failed to handle server msg: {:namespaces #{learning.web.goals.core}, :deleted #{}, :updated #{learning.web.goals.core}, :added #{}, :shadow.cljs.devtools.server.system-bus/topic :shadow.cljs.devtools.server.system-msg/resource-update}
java.lang.NoClassDefFoundError: Could not initialize class shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052$fn__13053$fn__13055
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052$fn__13053.invoke(warnings.clj:43)
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052.invoke(warnings.clj:43)
        at clojure.lang.LazySeq.sval(LazySeq.java:40)
        at clojure.lang.LazySeq.seq(LazySeq.java:49)
        at clojure.lang.RT.seq(RT.java:528)
        at clojure.core$seq__5124.invokeStatic(core.clj:137)
        at clojure.core.protocols$seq_reduce.invokeStatic(protocols.clj:24)
        at clojure.core.protocols$fn__7835.invokeStatic(protocols.clj:75)
        at clojure.core.protocols$fn__7835.invoke(protocols.clj:75)
        at clojure.core.protocols$fn__7781$G__7776__7794.invoke(protocols.clj:13)
        at clojure.core$reduce.invokeStatic(core.clj:6748)
        at clojure.core$into.invokeStatic(core.clj:6815)
        at clojure.core$into.invoke(core.clj:6807)
        at shadow.build.warnings$get_source_excerpts.invokeStatic(warnings.clj:54)
        at shadow.build.warnings$get_source_excerpts.invoke(warnings.clj:9)
        at shadow.build.warnings$get_source_excerpt.invokeStatic(warnings.clj:57)
        at shadow.build.warnings$get_source_excerpt.invoke(warnings.clj:56)
        at shadow.build.compiler$maybe_compile_cljs$fn__14838.invoke(compiler.clj:645)
        at shadow.build.compiler$maybe_compile_cljs.invokeStatic(compiler.clj:621)
        at shadow.build.compiler$maybe_compile_cljs.invoke(compiler.clj:599)
        at shadow.build.compiler$generate_output_for_source.invokeStatic(compiler.clj:670)
        at shadow.build.compiler$generate_output_for_source.invoke(compiler.clj:660)
        at shadow.build.compiler$par_compile_one.invokeStatic(compiler.clj:714)
        at shadow.build.compiler$par_compile_one.invoke(compiler.clj:673)
        at shadow.build.compiler$par_compile_cljs_sources$fn__14868$iter__14869__14873$fn__14874$fn__14875$fn__14876.invoke(compiler.clj:765)
        at clojure.lang.AFn.applyToHelper(AFn.java:152)
        at clojure.lang.AFn.applyTo(AFn.java:144)
        at clojure.core$apply.invokeStatic(core.clj:657)
        at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1965)
        at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1965)
        at clojure.lang.RestFn.invoke(RestFn.java:425)
        at clojure.lang.AFn.applyToHelper(AFn.java:156)
        at clojure.lang.RestFn.applyTo(RestFn.java:132)
        at clojure.core$apply.invokeStatic(core.clj:661)
        at clojure.core$bound_fn_STAR_$fn__5471.doInvoke(core.clj:1995)
        at clojure.lang.RestFn.invoke(RestFn.java:397)
        at clojure.lang.AFn.call(AFn.java:18)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

After restarting server, and re-compiling, it shows me that I have an error in the repl:

[:devcards] Build failure:
------ ERROR -------------------------------------------------------------------
 File: /home/matthys/projects/personal/learning/src/learning/web/goals/core.cljs:160:22
--------------------------------------------------------------------------------
 157 |       (du/ds-by-id ::goal-brainstorm-done (fn [_] [:goal-brainstorm-task/done]))
 158 |       (du/ds-by-id ::goal-brainstorm-data
 159 |                    (fn [route]
 160 |                      (let [{{:keys [goal-brainstorm/date-str]} (route/task route)}]
----------------------------^---------------------------------------------------
Call to cljs.core/let did not conform to spec
-- Syntax error -------------------

  ([{{:keys [goal-brainstorm/date-str]} (route/task route)}] ...)
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

should have additional elements. The next element ":args" should satisfy

  any?

-- Relevant specs -------

:clojure.core.specs.alpha/bindings:
  (clojure.spec.alpha/and
   clojure.core/vector?
   (clojure.spec.alpha/* :clojure.core.specs.alpha/binding))

-------------------------
Detected 1 error

--------------------------------------------------------------------------------
 161 |                        [:goal/brainstorm date-str])))
 162 | 
 163 |       (du/ds-by-id ::goal-mission-done (fn [_] [:goal-mission-task/done]))
 164 |       (du/ds-by-id ::goal-mission-data
--------------------------------------------------------------------------------

What I would expect to happen:
I expect shadow-cljs to tell me that there is an syntax error in my code, without requiring me to restart the server.

Let me know if you require further information.

@thheller
Copy link
Owner

thheller commented May 6, 2018

Hmm I have seen this error before but IIRC it was related to AOT compilation which is not active anymore.

Can you reproduce this reliably? I have no idea where to look.

@mjmeintjes
Copy link
Author

I'm still trying to reproduce this issue, but in mean time will keep updating this issue as I encounter it.

What I've found now is that sometimes if this error happens, and I press CTRL-C, the server hangs on shutting down ...

I have to close the terminal when this happens, as it does not want to shut down at all.

If I want to clean slate everything related to shadow-cljs, is it enough to delete the .shadow-cljs directory, or is there somewhere else that files are stored?

I can probably try deleting the m2 directory as well.

@thheller
Copy link
Owner

thheller commented May 9, 2018

All state is in .shadow-cljs but deleting this should never be necessary. I'd much rather try to track this down and fix it. Still not a clue where to look though.

I have no idea why the shutdown might fail. The next time it does please include a jstack <pid> report. The PID of the process should be in .shadow-cljs/server.pid or listed via jps. This produces a stack dump and might provide a clue where it hangs.

Do you use lein or tools.deps?

@mjmeintjes
Copy link
Author

No, just using plain shadow-cljs.

I run shadow-cljs server from the command line. Then I do a cider-connect, and then cider-create-sibling-cljs-repl. Then I select my build (node in this case).

I then just use emacs to evaluate code.

Thought I'd just clean everything out to ensure that I don't have some old files laying around somewhere that might be causing this, as I've been using shadow-cljs for a couple of months now.

Here's another exception that I'm getting every now and then, it seems related:

[2018-05-09 21:55:25 - WARNING] failed to handle server msg: {:namespaces #{learning.tools.data-loading}, :deleted #{}, :updated #{learning.tools.data-loading}, :added #{}, :shadow.cljs.devtools.server.system-bus/topic :shadow.cljs.devtools.server.system-msg/resource-update}
java.lang.ExceptionInInitializerError
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052$fn__13053.invoke(warnings.clj:43)
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052.invoke(warnings.clj:43)
        at clojure.lang.LazySeq.sval(LazySeq.java:40)
        at clojure.lang.LazySeq.seq(LazySeq.java:49)
        at clojure.lang.RT.seq(RT.java:528)
        at clojure.core$seq__5124.invokeStatic(core.clj:137)
        at clojure.core.protocols$seq_reduce.invokeStatic(protocols.clj:24)
        at clojure.core.protocols$fn__7835.invokeStatic(protocols.clj:75)
        at clojure.core.protocols$fn__7835.invoke(protocols.clj:75)
        at clojure.core.protocols$fn__7781$G__7776__7794.invoke(protocols.clj:13)
        at clojure.core$reduce.invokeStatic(core.clj:6748)
        at clojure.core$into.invokeStatic(core.clj:6815)
        at clojure.core$into.invoke(core.clj:6807)
        at shadow.build.warnings$get_source_excerpts.invokeStatic(warnings.clj:54)
        at shadow.build.warnings$get_source_excerpts.invoke(warnings.clj:9)
        at shadow.build$enhance_warnings.invokeStatic(build.clj:33)
        at shadow.build$enhance_warnings.invoke(build.clj:20)
        at shadow.build$extract_build_info$fn__15171.invoke(build.clj:90)
        at clojure.core$map$fn__5587.invoke(core.clj:2745)
        at clojure.lang.LazySeq.sval(LazySeq.java:40)
        at clojure.lang.LazySeq.seq(LazySeq.java:49)
        at clojure.lang.ChunkedCons.chunkedNext(ChunkedCons.java:59)
        at clojure.core$chunk_next.invokeStatic(core.clj:700)
        at clojure.core.protocols$fn__7847.invokeStatic(protocols.clj:137)
        at clojure.core.protocols$fn__7847.invoke(protocols.clj:124)
        at clojure.core.protocols$fn__7807$G__7802__7816.invoke(protocols.clj:19)
        at clojure.core.protocols$seq_reduce.invokeStatic(protocols.clj:31)
        at clojure.core.protocols$fn__7835.invokeStatic(protocols.clj:75)
        at clojure.core.protocols$fn__7835.invoke(protocols.clj:75)
        at clojure.core.protocols$fn__7781$G__7776__7794.invoke(protocols.clj:13)
        at clojure.core$reduce.invokeStatic(core.clj:6748)
        at clojure.core$into.invokeStatic(core.clj:6815)
        at clojure.core$into.invoke(core.clj:6807)
        at shadow.build$extract_build_info.invokeStatic(build.clj:92)
        at shadow.build$extract_build_info.invoke(build.clj:63)
        at shadow.build$update_build_info_after_compile.invokeStatic(build.clj:103)
        at shadow.build$update_build_info_after_compile.invoke(build.clj:101)
        at shadow.build$compile.invokeStatic(build.clj:291)
        at shadow.build$compile.invoke(build.clj:271)
        at shadow.cljs.devtools.server.worker.impl$build_compile.invokeStatic(impl.clj:188)
        at shadow.cljs.devtools.server.worker.impl$build_compile.invoke(impl.clj:176)
        at shadow.cljs.devtools.server.worker.impl$do_resource_update.invokeStatic(impl.clj:523)
        at shadow.cljs.devtools.server.worker.impl$do_resource_update.invoke(impl.clj:488)
        at shadow.cljs.devtools.server.util$server_thread$fn__16431$fn__16432$fn__16436.invoke(util.clj:222)
        at shadow.cljs.devtools.server.util$server_thread$fn__16431$fn__16432.invoke(util.clj:221)
        at shadow.cljs.devtools.server.util$server_thread$fn__16431.invoke(util.clj:196)
        at clojure.core.async$thread_call$fn__7242.invoke(async.clj:441)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: Can't resolve find-ns
        at clojure.lang.Util.runtimeException(Util.java:221)
        at clojure.lang.LispReader$EvalReader.invoke(LispReader.java:1315)
        at clojure.lang.LispReader$DispatchReader.invoke(LispReader.java:843)
        at clojure.lang.LispReader.read(LispReader.java:275)
        at clojure.lang.LispReader.read(LispReader.java:206)
        at clojure.lang.LispReader.read(LispReader.java:195)
        at clojure.lang.RT.readString(RT.java:1871)
        at clojure.lang.RT.readString(RT.java:1866)
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052$fn__13053$fn__13055.<clinit>(warnings.clj:44)
        ... 51 more

@thheller
Copy link
Owner

thheller commented May 9, 2018

Caused by: java.lang.RuntimeException: Can't resolve find-ns
        at clojure.lang.Util.runtimeException(Util.java:221)
        at clojure.lang.LispReader$EvalReader.invoke(LispReader.java:1315)
        at clojure.lang.LispReader$DispatchReader.invoke(LispReader.java:843)
        at clojure.lang.LispReader.read(LispReader.java:275)
        at clojure.lang.LispReader.read(LispReader.java:206)
        at clojure.lang.LispReader.read(LispReader.java:195)
        at clojure.lang.RT.readString(RT.java:1871)
        at clojure.lang.RT.readString(RT.java:1866)
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052$fn__13053$fn__13055.<clinit>(warnings.clj:44)
        ... 51 more

This is so extremely strange ... There is not a single use of read-string in warnings.clj and find-ns is a clojure built-in so I have no clue why that wouldn't resolve.

I am suspecting cider-nrepl currently as that might be doing stuff on connect. Maybe it uses tools.namespace or so which may mess up the current shadow-cljs server state.

@mjmeintjes
Copy link
Author

I think I'm able to reproduce it now.

  1. I run shadow-cljs server from the command line. Then I do a cider-connect, and then cider-create-sibling-cljs-repl. Then I select my build (node in this case).
  2. I go to my code file, and run cider-repl-set-ns
  3. Add a syntax error (defn)
  4. See the following error:
[2018-05-09 22:21:48 - WARNING] failed to handle server msg: {:namespaces #{learning.tools.migrate-to-separate-dbs}, :deleted #{}, :updated #{learning.tools.migrate-to-separate-dbs}, :added #{}, :shadow.cljs.devtools.server.system-bus/topic :shadow.cljs.devtools.server.system-msg/resource-update}
java.lang.ExceptionInInitializerError
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052$fn__13053.invoke(warnings.clj:43)
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052.invoke(warnings.clj:43)
        at clojure.lang.LazySeq.sval(LazySeq.java:40)
        at clojure.lang.LazySeq.seq(LazySeq.java:49)
        at clojure.lang.RT.seq(RT.java:528)
        at clojure.core$seq__5124.invokeStatic(core.clj:137)
        at clojure.core.protocols$seq_reduce.invokeStatic(protocols.clj:24)
        at clojure.core.protocols$fn__7835.invokeStatic(protocols.clj:75)
        at clojure.core.protocols$fn__7835.invoke(protocols.clj:75)
        at clojure.core.protocols$fn__7781$G__7776__7794.invoke(protocols.clj:13)
        at clojure.core$reduce.invokeStatic(core.clj:6748)
        at clojure.core$into.invokeStatic(core.clj:6815)
        at clojure.core$into.invoke(core.clj:6807)
        at shadow.build.warnings$get_source_excerpts.invokeStatic(warnings.clj:54)
        at shadow.build.warnings$get_source_excerpts.invoke(warnings.clj:9)
        at shadow.build.warnings$get_source_excerpt.invokeStatic(warnings.clj:57)
        at shadow.build.warnings$get_source_excerpt.invoke(warnings.clj:56)
        at shadow.build.compiler$maybe_compile_cljs$fn__14838.invoke(compiler.clj:645)
        at shadow.build.compiler$maybe_compile_cljs.invokeStatic(compiler.clj:621)
        at shadow.build.compiler$maybe_compile_cljs.invoke(compiler.clj:599)
        at shadow.build.compiler$generate_output_for_source.invokeStatic(compiler.clj:670)
        at shadow.build.compiler$generate_output_for_source.invoke(compiler.clj:660)
        at shadow.build.compiler$par_compile_one.invokeStatic(compiler.clj:714)
        at shadow.build.compiler$par_compile_one.invoke(compiler.clj:673)
        at shadow.build.compiler$par_compile_cljs_sources$fn__14868$iter__14869__14873$fn__14874$fn__14875$fn__14876.invoke(compiler.clj:765)
        at clojure.lang.AFn.applyToHelper(AFn.java:152)
        at clojure.lang.AFn.applyTo(AFn.java:144)
        at clojure.core$apply.invokeStatic(core.clj:657)
        at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1965)
        at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1965)
        at clojure.lang.RestFn.invoke(RestFn.java:425)
        at clojure.lang.AFn.applyToHelper(AFn.java:156)
        at clojure.lang.RestFn.applyTo(RestFn.java:132)
        at clojure.core$apply.invokeStatic(core.clj:661)
        at clojure.core$bound_fn_STAR_$fn__5471.doInvoke(core.clj:1995)
        at clojure.lang.RestFn.invoke(RestFn.java:397)
        at clojure.lang.AFn.call(AFn.java:18)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: Can't resolve find-ns
        at clojure.lang.Util.runtimeException(Util.java:221)
        at clojure.lang.LispReader$EvalReader.invoke(LispReader.java:1315)
        at clojure.lang.LispReader$DispatchReader.invoke(LispReader.java:843)
        at clojure.lang.LispReader.read(LispReader.java:275)
        at clojure.lang.LispReader.read(LispReader.java:206)
        at clojure.lang.LispReader.read(LispReader.java:195)
        at clojure.lang.RT.readString(RT.java:1871)
        at clojure.lang.RT.readString(RT.java:1866)
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052$fn__13053$fn__13055.<clinit>(warnings.clj:44)
        ... 41 more

It seems likely that it is something to do with cider, because if take cider out of the equation by running the following:

shadow-cljs clj-repl
(shadow.cljs.devtools.api/watch :node)
(shadow.cljs.devtools.api/repl :node)
(in-ns 'learning.tools.migrate-to-separate-dbs)

And then add the syntax error, it displays the correct syntax error information, as I would expect.

I will update cider to the latest version (0.17) as I'm running from trunk, and will report back if it happens again.

@mjmeintjes
Copy link
Author

Error is still there with latest version of cider.

I'll continue investigating and will update if anything changes, or if it hangs indefinitely again.

@bbatsov
Copy link

bbatsov commented May 9, 2018

@mjmeintjes Did this work for you before and stopped working recently?

I'm asking because I'm quite puzzled by the error in general and I don't recall any recent changes in CIDER that could cause something like this.

@mjmeintjes
Copy link
Author

@bbatsov Sorry, difficult to say when this error started. I only noticed it for the past couple of weeks.

@mjmeintjes
Copy link
Author

@thheller I've experienced the problem where shadow-cljs hangs after pressing CTRL-C again.

I ran jstack, and got the following output:
https://gist.github.com/mjmeintjes/ef5933b2971f50ea33fc0218a08affd2

The reason that I stopped the server is because I got the following error any time code failed to compile:

[2018-05-21 22:26:10 - WARNING] failed to handle server msg: {:namespaces #{learning.web.writing.core}, :deleted #{}, :updated #{learning.web.writing.core}, :added #{}, :shadow.cljs.devtools.server.system-bus/topic :shadow.cljs.devtools.server.system-msg/resource-update}
java.lang.NoClassDefFoundError: Could not initialize class shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052$fn__13053$fn__13055
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052$fn__13053.invoke(warnings.clj:43)
        at shadow.build.warnings$get_source_excerpts$iter__13047__13051$fn__13052.invoke(warnings.clj:43)
        at clojure.lang.LazySeq.sval(LazySeq.java:40)
        at clojure.lang.LazySeq.seq(LazySeq.java:49)
        at clojure.lang.RT.seq(RT.java:528)
        at clojure.core$seq__5124.invokeStatic(core.clj:137)
        at clojure.core.protocols$seq_reduce.invokeStatic(protocols.clj:24)
        at clojure.core.protocols$fn__7835.invokeStatic(protocols.clj:75)
        at clojure.core.protocols$fn__7835.invoke(protocols.clj:75)
        at clojure.core.protocols$fn__7781$G__7776__7794.invoke(protocols.clj:13)
        at clojure.core$reduce.invokeStatic(core.clj:6748)
        at clojure.core$into.invokeStatic(core.clj:6815)
        at clojure.core$into.invoke(core.clj:6807)
        at shadow.build.warnings$get_source_excerpts.invokeStatic(warnings.clj:54)
        at shadow.build.warnings$get_source_excerpts.invoke(warnings.clj:9)
        at shadow.build$enhance_warnings.invokeStatic(build.clj:33)
        at shadow.build$enhance_warnings.invoke(build.clj:20)
        at shadow.build$extract_build_info$fn__15171.invoke(build.clj:90)
        at clojure.core$map$fn__5587.invoke(core.clj:2745)
        at clojure.lang.LazySeq.sval(LazySeq.java:40)
        at clojure.lang.LazySeq.seq(LazySeq.java:49)
        at clojure.lang.ChunkedCons.chunkedNext(ChunkedCons.java:59)
        at clojure.core$chunk_next.invokeStatic(core.clj:700)
        at clojure.core.protocols$fn__7847.invokeStatic(protocols.clj:137)
        at clojure.core.protocols$fn__7847.invoke(protocols.clj:124)
        at clojure.core.protocols$fn__7807$G__7802__7816.invoke(protocols.clj:19)
        at clojure.core.protocols$seq_reduce.invokeStatic(protocols.clj:31)
        at clojure.core.protocols$fn__7835.invokeStatic(protocols.clj:75)
        at clojure.core.protocols$fn__7835.invoke(protocols.clj:75)
        at clojure.core.protocols$fn__7781$G__7776__7794.invoke(protocols.clj:13)
        at clojure.core$reduce.invokeStatic(core.clj:6748)
        at clojure.core$into.invokeStatic(core.clj:6815)
        at clojure.core$into.invoke(core.clj:6807)
        at shadow.build$extract_build_info.invokeStatic(build.clj:92)
        at shadow.build$extract_build_info.invoke(build.clj:63)
        at shadow.build$update_build_info_after_compile.invokeStatic(build.clj:103)
        at shadow.build$update_build_info_after_compile.invoke(build.clj:101)
        at shadow.build$compile.invokeStatic(build.clj:295)
        at shadow.build$compile.invoke(build.clj:275)
        at shadow.cljs.devtools.server.worker.impl$build_compile.invokeStatic(impl.clj:188)
        at shadow.cljs.devtools.server.worker.impl$build_compile.invoke(impl.clj:176)
        at shadow.cljs.devtools.server.worker.impl$do_resource_update.invokeStatic(impl.clj:523)
        at shadow.cljs.devtools.server.worker.impl$do_resource_update.invoke(impl.clj:488)
        at shadow.cljs.devtools.server.util$server_thread$fn__16436$fn__16437$fn__16441.invoke(util.clj:222)
        at shadow.cljs.devtools.server.util$server_thread$fn__16436$fn__16437.invoke(util.clj:221)
        at shadow.cljs.devtools.server.util$server_thread$fn__16436.invoke(util.clj:196)
        at clojure.core.async$thread_call$fn__7242.invoke(async.clj:441)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

@thheller
Copy link
Owner

thheller commented May 21, 2018

@mjmeintjes Which shadow-cljs version is this and what was the command used to start shadow-cljs?

Ahh .. probably still 2.3.19 and shadow-cljs clj-repl

@mjmeintjes
Copy link
Author

Upgraded to 2.3.20 when I got this error. But I've since updated to 2.3.23.

Random thought: can it have something to do with reflection, because I'm getting the following warnings when starting shadow-cljs:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.xnio.nio.NioXnio$2 (file:/home/matthys/.m2/repository/org/jboss/xnio/xnio-nio/3.3.8.Final/xnio-nio-3.3.8.Final.jar) to constructor sun.nio.ch.EPollSelectorProvider()
WARNING: Please consider reporting this to the maintainers of org.xnio.nio.NioXnio$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

@thheller
Copy link
Owner

Those warnings are unrelated. Those are Java9 issues with the IO library undertow uses (the HTTP server). On Windows they are already fixed and I no longer get them. Can you check your deps and see if you get the [org.jboss.xnio/xnio-nio "3.3.8.Final" :scope "runtime"] version?

Anyways, I still do not have the slightest clue about the NoClassDefFoundError error. The "hang" is probably the same reason as #186, guess I really need to stop using spawnSync.

@mjmeintjes
Copy link
Author

Just an update on this: I've isolated this into a docker container, and I'm pretty sure that it is not specific to my computer.

I've created a docker container with a clean emacs, with just the latest cider version installed, and created a minimal project, and the problem still occurs.

Next step is now going to go through different cider versions to see if I can isolate when this problem started.

@mjmeintjes
Copy link
Author

Ok, so I've done some extensive research into this bug, as it is a bit of a show stopper for me.

Here's what I found:

  • @bbatsov this error seems to occur with cider 0.17 and up, when using cider-create-sibling-cljs-repl
  • It does not seem to occur when I just cider-connect, and then manually run watch and nrepl-select

I have set up a docker-compose project that you can use to check this out. It is a bit involved, but there are instructions in the readme:
https://github.com/mjmeintjes/shadow-cljs-nodejs-bug

At least for now, my most pressing problem is solved because I can fallback to manually running watch and nrepl-select.

@mjmeintjes
Copy link
Author

Sorry, seems I was wrong. The error still crops up when running (do (shadow.cljs.devtools.api/watch :devcards) (shadow.cljs.devtools.api/nrepl-select :devcards)) on cider 0.17.

@mjmeintjes
Copy link
Author

Sorry for the spam on this issue.

For now, the only solution seems to be to downgrade to cider 0.16.

Unfortunately, that doesn't seem to be an easy thing to do (or at least I couldn't figure out how to do it easily). Finally, I found the easiest way is to use el-get, and referencing a specific commit.

For anyone else wanting to do this, add the following to your emacs init file:

(add-to-list 'load-path "~/.emacs.d/el-get/el-get")

(unless (require 'el-get nil 'noerror)
  (with-current-buffer
      (url-retrieve-synchronously
       "https://raw.githubusercontent.com/dimitri/el-get/master/el-get-install.el")
    (goto-char (point-max))
    (eval-print-last-sexp)))

(add-to-list 'el-get-recipe-path "~/.emacs.d/el-get-user/recipes")
(el-get 'sync)

(el-get-bundle! cider
                :checkout "74f7901b416efbd032bb4f8b5c25f57fdf731115")

@mjmeintjes
Copy link
Author

Ok, so after using cider 0.16 for a while without any problems, the issue is now cropping up again.

@bbatsov
Copy link

bbatsov commented May 23, 2018

There are almost no differences middleware-wise between CIDER 0.16 and 0.17, so I was quite surprised by your initial discovery. Are you certain that's something to do with CIDER, btw - perhaps it's some bug in shadow's nREPL middleware?

@bbatsov
Copy link

bbatsov commented May 23, 2018

I also wonder who exactly does the track state middleware play into all of this. The only thing from the log I'm familiar with is:

[2018-05-21 22:26:10 - WARNING] failed to handle server msg: {:namespaces #{learning.web.writing.core}, :deleted #{}, :updated #{learning.web.writing.core}, :added #{}, :shadow.cljs.devtools.server.system-bus/topic :shadow.cljs.devtools.server.system-msg/resource-update}

That's how CIDER keeps track of the state of the namespaces users interact with.

@thheller
Copy link
Owner

It is absolutely possible that my middleware does something its not supposed to but the weird thing is that the error is happening in an entirely unrelated thread. In development "watch" mode a worker-thread is spawned which is responsible for coordinating the various events that can happen.

The above message is sent from the classpath watch thread (another totally unrelated thread) when it finds modified files on the classpath and notifies the worker. The worker then processes the message and triggers a recompile which fails.

@mjmeintjes can you test running shadow-cljs watch independently and just use cider-connect + nrepl-select, without starting the watch via nREPL. Maybe there is some weirdness going on with the interruptible-eval middleware since that runs things in a thread-pool?

@mjmeintjes
Copy link
Author

@thheller That seems to solve the problem.

@thheller
Copy link
Owner

I once thought I understood classloaders but I guess I don't. This was just a wild guess, not actually a clue why it would affect anything. Maybe some of the cider-nrepl middleware manipulates the classloaders?

@bbatsov
Copy link

bbatsov commented May 24, 2018 via email

@mjmeintjes
Copy link
Author

mjmeintjes commented May 24, 2018 via email

@thheller
Copy link
Owner

I have a new theory.

shadow-cljs has had other troublesome interactions with cider in the form of *print-length* which I think cider sets globally for each nREPL session. Since some internals of the builds used pr-str to write some .edn files those suddenly had some crucial info elided due to the fixed *print-length*. I added a safe-pr-str that resets all bindings for this reason.

Maybe somehow some bindings "leak" into the worker threads. Not a clue how that would lead to a classloader problem but that would explain why it works when the watch is launched externally.

thheller added a commit that referenced this issue May 25, 2018
async/thread keeps bindings which might be causing #273 when
starting the watch from a REPL thread
@thheller
Copy link
Owner

I just release 2.3.24 which uses a dedicated thread instead of async/thread which preserves bindings.

@mjmeintjes please try that if you get a chance. my emacs-fu is too weak to get this setup properly.

@mjmeintjes
Copy link
Author

Still giving the same error using 2.3.25. The only difference is that the error is now printing in the REPL buffer in emacs, which is an improvement over just displaying "Compiling...".

It is also displaying the following line before the error.

 Exception in thread "async-dispatch-6" java.lang.ExceptionInInitializerError

@mitchelkuijpers
Copy link

I am getting this with 2.3.35:

Exception in thread "async-dispatch-1" 
java.lang.ExceptionInInitializerError
	at shadow.cljs.devtools.errors$user_friendly_error.invokeStatic(errors.clj:322)
	at shadow.cljs.devtools.errors$user_friendly_error.invoke(errors.clj:321)
	at shadow.cljs.devtools.server.util$print_build_failure.invokeStatic(util.clj:123)
	at shadow.cljs.devtools.server.util$print_build_failure.invoke(util.clj:121)
	at shadow.cljs.devtools.server.util$print_worker_out.invokeStatic(util.clj:141)
	at shadow.cljs.devtools.server.util$print_worker_out.invoke(util.clj:125)
	at shadow.cljs.devtools.server.util$stdout_dump$fn__67641$state_machine__7987__auto____67646$fn__67649.invoke(util.clj:188)
	at shadow.cljs.devtools.server.util$stdout_dump$fn__67641$state_machine__7987__auto____67646.invoke(util.clj:188)
	at clojure.core.async.impl.ioc_macros$run_state_machine.invokeStatic(ioc_macros.clj:973)
	at clojure.core.async.impl.ioc_macros$run_state_machine.invoke(ioc_macros.clj:972)
	at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invokeStatic(ioc_macros.clj:977)
	at clojure.core.async.impl.ioc_macros$run_state_machine_wrapped.invoke(ioc_macros.clj:975)
	at clojure.core.async.impl.ioc_macros$take_BANG_$fn__8005.invoke(ioc_macros.clj:986)
	at clojure.core.async.impl.channels.ManyToManyChannel$fn__2872$fn__2873.invoke(channels.clj:95)
	at clojure.lang.AFn.run(AFn.java:22)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.RuntimeException: Can't resolve find-ns
	at clojure.lang.Util.runtimeException(Util.java:221)
	at clojure.lang.LispReader$EvalReader.invoke(LispReader.java:1315)
	at clojure.lang.LispReader$DispatchReader.invoke(LispReader.java:843)
	at clojure.lang.LispReader.read(LispReader.java:275)
	at clojure.lang.LispReader.read(LispReader.java:206)
	at clojure.lang.LispReader.read(LispReader.java:195)
	at clojure.lang.RT.readString(RT.java:1871)
	at clojure.lang.RT.readString(RT.java:1866)
	at shadow.cljs.devtools.errors$user_friendly_error$fn__67472.<clinit>(errors.clj:322)
	... 18 more
 JS runtime connected.
[:app] Compiling ...
[:app] Build failure:

@thheller
Copy link
Owner

thheller commented Aug 6, 2018

2.4.32 may have fixed this if its still a problem for you.

@mitchelkuijpers
Copy link

Yes this fixes it for me! 🎉

@thheller
Copy link
Owner

thheller commented Aug 8, 2018

Great. I still don't actually have a slightest clue what the actual problem is but removing the problematic tools.logging seems to fix it.

@thheller thheller closed this as completed Aug 8, 2018
@zcaudate
Copy link

I had the same RT.readString("#=(find-ns <ns>)") problem. This issue as well as the subsequent posts on slack and google groups helped me understand what was happening because it's a really frustrating bug.

I haven't used tools.logging but I'm assuming that it's using macros to generate the logging forms. What is should be doing is calling (.getName *ns*) on the macro to get the symbol instead of the actual dynamic *ns* object. I don't think this will necessary cause a problem as logging only needs the static reference at compile time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants