search

thheller / shadow-cljs

ClojureScript compilation made easy
https://github.com/thheller/shadow-cljs
Eclipse Public License 1.0
2.27k stars 180 forks source link

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

Closed mjmeintjes closed 6 years ago

mjmeintjes commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago 
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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

mjmeintjes commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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:

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

bbatsov commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@thheller That seems to solve the problem.

thheller commented 6 years ago

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 commented 6 years ago

Some middleware uses dynapath to add a couple of jars to the classpath, but I don’t recall any classloader manipulations. I can’t check right now.

On Thu, 24 May 2018 at 17:21, Thomas Heller notifications@github.com wrote:

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?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thheller/shadow-cljs/issues/273#issuecomment-391733141, or mute the thread https://github.com/notifications/unsubscribe-auth/AAGVyjwC_y3l6uk4tYFJm_O3zfT9xvZsks5t1sIEgaJpZM4Tz5l1 .

-- Best Regards, Bozhidar Batsov

http://www.batsov.com

mjmeintjes commented 6 years ago

I'll try to test several different versions of shadow-cljs over the weekend to see if some specific change introduced this problem, or if it has always been a problem.

thheller commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

mitchelkuijpers commented 6 years ago

Yes this fixes it for me! :tada:

thheller commented 6 years ago

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.

zcaudate commented 3 years ago

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.