Clojurians Log v2
graalvm 2024-06-05
Has anyone come across this error:
Error: Unsupported features in 2 methods
Detailed message:
Error: Frame states being merged are incompatible: unbalanced monitors - locked objects do not match
This frame state: [locals: [_,3,_,_,_,_,_,_,_] stack: [6] locks: [] rethrowException]
Other frame state: [locals: [_,3,_,_,_,_,_,_,_] stack: [20] locks: [13 / 4] rethrowException]
Parser context: clojure.tools.logging$fn__328$log_uncapture_BANG___332.invoke(logging.clj:188) [bci: 15, intrinsic: false]
15: checkcast #30 // clojure.lang.IFn
18: aload_0
19: getfield #1 // orig:java.lang.Object
22: invokeinterface#5, 2 // clojure.lang.IFn.invoke:(java.lang.Object)java.lang.Object
Call path from entry point to clojure.tools.logging$fn__328$log_uncapture_BANG___332.invoke():
at clojure.tools.logging$fn__328$log_uncapture_BANG___332.invoke(logging.clj:184)
at clojure.core$PrintWriter_on$fn__7574.invoke(core_print.clj:573)
at clojure.tools.logging.proxy$java.io.ByteArrayOutputStream$ff19274a.toString(Unknown Source)
at java.lang.String.valueOf(String.java:4465)
at com.oracle.svm.core.jni.functions.JNIFunctions$Support.getMethodID(JNIFunctions.java:1332)
at com.oracle.svm.core.jni.functions.JNIFunctions.ThrowNew(JNIFunctions.java:896)
at com.oracle.svm.core.code.IsolateEnterStub.JNIFunctions_ThrowNew_837474fdc53acd32de3ea686903bfa38552734c3(generated:0)
Original exception that caused the problem: org.graalvm.compiler.core.common.PermanentBailoutException: Frame states being merged are incompatible: unbalanced monitors - locked objects do not match
This frame state: [locals: [_,3,_,_,_,_,_,_,_] stack: [6] locks: [] rethrowException]
Other frame state: [locals: [_,3,_,_,_,_,_,_,_] stack: [20] locks: [13 / 4] rethrowException]
Parser context: clojure.tools.logging$fn__328$log_uncapture_BANG___332.invoke(logging.clj:188) [bci: 15, intrinsic: false]
15: checkcast #30 // clojure.lang.IFn
18: aload_0
19: getfield #1 // orig:java.lang.Object
22: invokeinterface#5, 2 // clojure.lang.IFn.invoke:(java.lang.Object)java.lang.Objectnative-image with [ferret "0.4.0-171a575"] ( https://clojars.org/ferret/versions/0.4.0-171a575 ) as a dep...
that code uses the locking macro that had balanced monitor issues fixed in Clojure 1.10.2
in case that is somehow relevant
Cheers, maybe...
My code deps on [org.clojure/clojure "1.11.1"]
Is it possible that another dep is pulling in another clojure version?
I'm guessing so since:
$ ls -l ~/.m2/repository/org/clojure/clojure/
total 44
drwxr-xr-x 2 ingy ingy 4096 Jun 5 21:15 1.10.0/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 21:15 1.10.1/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 21:15 1.10.3/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 21:15 1.11.1/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 22:05 1.3.0/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 22:05 1.3.0-alpha5/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 21:15 1.4.0/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 21:15 1.5.1/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 21:15 1.6.0/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 21:15 1.8.0/
drwxr-xr-x 2 ingy ingy 4096 Jun 5 21:15 1.9.0/same result after rm -r ~/.m2 and rebuilding.
But I only see one clojure jar file:
$ find ~/.m2/repository/org/clojure/clojure/ -name '*.jar'
/home/ingy/.m2/repository/org/clojure/clojure/1.11.1/clojure-1.11.1.jarwhat's up with the other version dirs?
It looks like ferret has compiled clojure code in it. Which is typically a no-no for clojure libs. And this could mean you are getting an old version of clojure embedded in ferret.
> what's up with the other version dirs? Do you mean under your m2 repository? That's just versions of clojure that happened to be dependencies that were downloaded during normal everyday usage.
> same result after rm -r ~/.m2 and rebuilding.
Yes that would be expected.
Download ferret jar and look at contents. Lotsa .class files.
what do you mean during normal everyday usage.?
I literally removed the .m2 dir entirely and ran one build command and got all that
Well, when you use clojure for anything. All maven deps are cached under ~/.m2/repository . It's a local-global cache for maven deps.
Right but only one of those dirs has a jar file in it
1.11.1 (my clojure dep)
Your main issue is ferret has what I expect is an old version of the clojure compiler embedded in it.
During dep expansion, other Clojure versions may be transitively encountered and their metadata (pom) versions downloaded
Agreed that compiled ferret is likely the source of old classes
I see
@lee can you give a URL pointing to what you are talking about? (compiled code in ferret)
Yep, sure! I went to http://repo.clojars.org and found the ferret jar you are using. Then I downloaded it like so:
wget unzip -l ferret-0.4.0-f402333.jar.class files in clojure lib that seem like they came from clojure source, it usually means the builder naively included compiled clojure sources. It is rarely a good idea to do this for a lib, and will cause headaches for users of that lib (like it is doing so now for you!)(since you are using ferret, you'd also find a copy of the jar under your ~/.m2/repository dir)
I see. https://github.com/nakkaya/ferret doesn't have any clojure code in it. I wouldn't have thought to look in the jar, and if I did I wouldn't have had a clue what to look for. Thanks...
It's a thing that happens sometimes and definitely trips folks up.
Oh I just read the ferret readme, I guess it is more intended to be used as an app than a lib.
But anyhoo if you wanna native-image ferret you'll likely have to fork and tweak.
I didn't notice that. That's interesting because I used it as an app and worked great. But then @markus.agwin and I were trying to use it as a lib. @markus.agwin said it worked with JVM as a lib but not with native-image
Yeah, that's just me glancing at the README... what do I know, really? simple_smile
For what we need, I can justify shelling out to an app or turning it into a bb pod...
Thanks for the help. Truly appreciated!
My pleasure! Alex had the answer, I just dug in a bit and rambled on about it.
@alexmiller ++ @lee ++