On Thu, Oct 8, 2009 at 9:38 AM, kunjaan <[email protected]> wrote: > > java.lang.ClassFormatError: Unknown constant tag 52 in class file > queries__init (Trial.clj:0)
It seems to be an infrequently-encountered bug in load-file. If you copy and paste the source code into the REPL and hit enter, it will evaluate the definitions one by one and work properly. The only other known workaround is to reorganize your code; it sometimes goes away (or sometimes just the number in the cryptic message changes, unfortunately) when you do so. It doesn't seem to be caused by a specific individual fragment of code, but instead somehow by the structure or arrangement of a whole group of definitions. Splitting them up among several namespaces seems particularly effective, suggesting it's the presence of certain combinations of code structures within a single file that provokes the bug. (I found this when I hit this bug, split the offending file in two as the first step in a binary search for the offending function because the error message wasn't so kind as to give me a usable line number, to name the function, or to be self-explanatory enough for me to know what to look for in the way of incorrect code, and then both files loaded without problems even though nothing else had been changed except to copy the ns macro invocation into the file that had been the second half of the original file, change the namespace name slightly, and add the necessary use clause pointing to the original namespace name.) I don't think Rich has ever weighed in with a definitive explanation for this one, or a better solution. If there's nothing too confidential/embarrassing/etc. in your source file, you might want to save a copy that reproduces this bug for Rich to use in locating it and in testing any fix. The message contents, dependence on load-file, and generally odd behavior suggests that the cause is a bug in the AOT compiler that causes it to scribble out of bounds of some field in some structure or another when constructing a classfile, overwriting some other field of that structure with a random and bogus value. I'm not sure how such a bug got in there, though; an infrequently-reproduced, context-and-perturbation-sensitive data-corruption like this is more typically seen in C code with buggy pointer arithmetic yet my understanding is that Clojure is implemented without any (Clojure-specific) JNI code. Java's array bounds checking and safe pointers make corruption bugs like this appearing in Java code unusual. Almost certainly, it occurs in some part of the code that works on a class's bytecodes either directly on disk or in the form of an unstructured Java byte array; hopefully that narrows it down to a few small areas of the total code base. Rewriting such code to treat a class as a more structured thing than just a byte array might be a useful long-term fix, and would help avoid other similar bugs, but would presumably be a *lot* of work. A short-term fix would be to check all index arithmetic in the same subset of the code, find the errors (of which apparently there are greater than zero), and fix them. An intermediate compromise would be to add bounds-checking logic (perhaps as asserts) to the same code, then use that and a source file that reproduces the bug to locate the indexing errors and fix them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
