Problem error message

[Four of Seventeen]

Got this doing a load-file:

#<CompilerException java.lang.ClassFormatError: Unknown constant tag
116 in class file hxr/priv/idb$eval__10559 (NO_SOURCE_FILE:0)>

Full stack trace:

java.lang.ClassFormatError: Unknown constant tag 116 in class file com/
foo/bar$eval__10559 (NO_SOURCE_FILE:0)
at clojure.lang.Compiler.eval(Compiler.java:4543)
at clojure.core$eval__3990.invoke(core.clj:1728)
at clojure.main$repl__5813$read_eval_print__5825.invoke(main.clj:176)
at clojure.main$repl__5813.doInvoke(main.clj:193)
at clojure.lang.RestFn.invoke(RestFn.java:548)
at org.enclojure.repl.main
$create_clojure_repl__53$repl_thread_fn__55.invoke(main.clj:96)
at clojure.lang.AFn.run(AFn.java:37)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ClassFormatError: Unknown constant tag 116 in
class file com/foo/bar$eval__10559
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.lang.ClassLoader.defineClass(ClassLoader.java:466)
at clojure.lang.DynamicClassLoader.defineClass
(DynamicClassLoader.java:42)
at clojure.lang.Compiler$FnExpr.getCompiledClass(Compiler.java:3417)
at clojure.lang.Compiler$FnExpr.eval(Compiler.java:3428)
at clojure.lang.Compiler.eval(Compiler.java:4531)
... 7 more

None of this points to a specific line in my code, and I'm fairly sure
it's syntactically valid. All I've done is to add a couple of function
and macro definitions since it was working last.

This is an excellent example of an unhelpful compile error -- I have
no frigging clue whatsoever where in a 2000-line source file the error
is, other than that it is presumably in a part I've changed recently.

Besides fixing this one to point to an actual line in the source file,
the message could use changing. "Unknown constant tag 116" is not
meaningful to the average Clojure coder. It does suggest maybe the
problem is with a constant, but the only two new constant definitions
are:

(def *work-queues* (atom {}))
(def *shuffled-workqueue-min* 100)

I don't see any obvious problems with either definition.

(The actual namespace is not com/foo/bar, of course. I don't think the
exact namespace name is relevant and it may subtly leak confidential
information so I took the liberty of changing it.)

[Stephen C. Gilardi]

On Jun 25, 2009, at 5:00 PM, Four of Seventeen wrote:

Got this doing a load-file:

#<CompilerException java.lang.ClassFormatError: Unknown constant tag
116 in class file hxr/priv/idb$eval__10559 (NO_SOURCE_FILE:0)>

That error appears to be coming from a Java-level class loader (see the ultimate "caused by" in the stack trace). If you search for it using Google, you'll see it's appeared in contexts other than Clojure. I read it as "I can't completely understand this .class file, failing, here's a message an error code about why".

I don't know in detail what the error means, but if I got it I would try this: delete any class files and/or jar files I compiled previously for this project and see if the problem happens when I'm sure I'm loading a clojure source file. Then try compiling again to check if the problem is reproducible.

--Steve

[Four of Seventeen]

On Jun 25, 5:23 pm, "Stephen C. Gilardi" <squee...@mac.com> wrote:
> That error appears to be coming from a Java-level class loader (see  
> the ultimate "caused by" in the stack trace). If you search for it  
> using Google, you'll see it's appeared in contexts other than Clojure.  
> I read it as "I can't completely understand this .class file, failing,  
> here's a message an error code about why".
>
> I don't know in detail what the error means, but if I got it I would  
> try this: delete any class files and/or jar files I compiled  
> previously for this project and see if the problem happens when I'm  
> sure I'm loading a clojure source file. Then try compiling again to  
> check if the problem is reproducible.

Didn't work. Thinking it might be environment specific, and using
netbeans, so I'm posting it in the enclojure group too.

Meanwhile I guess I'll fall back on the old, tedious debugging method
for cases like this: break everything up into separate modules and try
to compile each one until I find the one with the error, and then
whittle that one down until I've isolated the particular bit of code
Clojure doesn't like, then try to figure out what, if anything, is
wrong with it and tweak it until it works.

[Four of Seventeen]

On Jun 25, 10:09 pm, Four of Seventeen <fsevent...@gmail.com> wrote:
> Meanwhile I guess I'll fall back on the old, tedious debugging method
> for cases like this: break everything up into separate modules and try
> to compile each one until I find the one with the error, and then
> whittle that one down until I've isolated the particular bit of code
> Clojure doesn't like, then try to figure out what, if anything, is
> wrong with it and tweak it until it works.

OK, now it's hair-pulling-out time.

I started by moving a large number of general-purpose utility
functions and macros to a separate file, namespace, and NetBeans
project and adding it as a library to my original one, upon deciding
that a lot of this stuff is really not application-specific and will
be reusable outside of the one project. I also documented some
functions, made others private, and tweaked a few things, as well as
sorting out the imports in both projects.

The utility project built without a hitch, so I figured the error
hadn't been in that code. (Very little of it was new, so, not
surprising.)

Then I tried to build the main project. I ran into some ordinary
errors (missing imports, classpath fiddliness, and so forth, plus a
handful of compile errors in the new code I'd added since the last
successful load-file of that project's one source file) and fixed
these one by one, expecting to get the "Unknown constant tag 116"
error after a while, whereupon I was going to call it a night, and
tomorrow continue to break up the project into additional separate
source files by function (DAL code here, GUI code there, &c.) but ...

It didn't happen.

I didn't change anything in the main project except to remove
functions and macros moved to the util project, remove some imports,
add a library (the util project), and add a :use of that library. So
the error must have been in code that I removed, most likely, code I
moved to the utility library.

The error must have been in one of the functions I refactored during
the move. I made some tweaks, most notably I caught and fixed a bug in
the floor function (it was giving floor for floats and positive
ratios, but ceil for negative ratios) and changed some macros to use a
more idiomatic [[binds] & body] argument syntax instead of just [binds
& body] now that they were part of a more public, more reuse-oriented
API. I can't recall what else I changed, other than that it wasn't
much.

More and more, I begin to suspect either a bug in clojure or a bug in
enclojure. Rearranging code without changing it much shouldn't
ordinarily have such an effect. Particularly, none of the stuff I both
moved and changed had been new since the last successful load-file of
the original single source file, none of the stuff I moved without
changing triggered the error, none of the stuff I neither moved nor
changed triggered the error, and I didn't change anything I didn't
move except the initial ns block, until I started getting fixable
errors from the new code that had formerly apparently caused only the
"Unknown constant tag 116" error.

In other words, what I've already done seems to mean that that error
existed in no individual piece of my code. It didn't exist in the code
I didn't move, because it stopped occurring before I changed any of
that code; it didn't exist in the code I moved and didn't change,
because it stopped occurring without my changing that code; and it
didn't exist in the code I moved and did change, because all of that
code had been present prior to the changes that caused the "Unknown
constant tag 116" to start occurring, and had NOT changed as part of
the changes that caused the "Unknown constant tag 116" to start
occurring.

If the "Unknown constant tag 116" error was not in a specific piece of
my code, however, whose semantics are unchanged (except for fixing
bugs in the new code and in floor), then it must have been a bug in
clojure and/or enclojure, or else somehow a bug in the arrangement of
my code. The latter would mean something like a missing import or
suchlike, though, and since it had been one monolithic source
file ...

At this point, I'm chalking it up to a bug in the development tools
I'm using, or the language implementation itself. Which is bad. If it
happens again, I have no idea how to fix it other than to randomly
move stuff around and hope it goes away, knowing that that already
worked once by happenstance. And if it stubbornly persists, I'll have
to throw my hands up and stop work until a bug-fix is released. I
dread the possibility of that occurring.

So should you. The mere fact that a developer is now worrying about
such a work stoppage is a sign that clojure is not quite ready for
prime time after all. We should be able to have confidence that if we
write non-buggy code, it will compile and run, without the need for
magic rearranging of code to avoid provoking a showstopping
implementaton bug.

A few recent threads are about evangelizing clojure, getting it
accepted as a development language by project managers and the like,
so if that sort of thing is a priority, fixing whatever this problem
is is a priority. First, we'll need to determine whether it is in
clojure itself or enclojure. Unfortunately, I no longer have a source
artifact that provokes the bug so I can't set up eclipse and clojure-
dev (or whatever) to see if the bug occurs identically there. Perhaps
someone here who is a deep wizard with classloaders can guess from the
initial bug report. For what it's worth, the stack trace doesn't show
anything that looks enclojure-specific, just java.lang and
clojure.lang in the cause exception, which has me leaning towards
clojure itself containing the bug -- the worst-case scenario.

(At this point, we might even want to start considering a bug in JAVA
ITSELF, or in Sun's JVM.

user=> (System/getProperty "java.version")
"1.6.0_13"

in case this helps. 32-bit client VM on 32-bit Windows Vista on a 32-
bit, 2.5GHz dual-core Intel machine with 3GB RAM.)