seart-group / java-tree-sitter

Java bindings for tree-sitter
MIT License
31 stars 4 forks source link

`SIGSEGV` when loading in the generated library #138

Closed PawanKartikS closed 8 months ago

PawanKartikS commented 8 months ago

I followed the steps in the readme and now I seem to be getting SIGSEGV when loading in the library via System.load(). Here's the error:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00000001046f630c, pid=45986, tid=57199
#
# JRE version: Java(TM) SE Runtime Environment Oracle GraalVM 21.0.2+13.1 (21.0.2+13) (build 21.0.2+13-LTS-jvmci-23.1-b30)
# Java VM: Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 21.0.2+13.1 (21.0.2+13-LTS-jvmci-23.1-b30, mixed mode, sharing, tiered, jvmci, jvmci compiler, compressed oops, compressed class ptrs, g1 gc, bsd-aarch64)
# Problematic frame:
# V  [libjvm.dylib+0x54e30c]  jni_GetFieldID+0x148
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

This is on an M1 MBA running Sonoma.

dabico commented 8 months ago

Hi @PawanKartikS

As mentioned in #101, there is currently no out-of-the-box support for M1 Macs in the current distribution. Although we plan to address this at some point, our current project schedule means that it is not a priority. Until then, what you can do is compile the project on your machine locally, as outlined in the linked issue. I will close this issue since they are similar, but let us know if you have any additional problems.

PawanKartikS commented 8 months ago

Thank you for the suggestion. I've made the appropriate changes and the loading still fails. I have a simple class that does nothing other than call System.load().

dabico commented 8 months ago

In that case, this warrants its separate issue. The core dump you provided is not enough for me to make any form of accurate assessment of the problem, would you be so kind as to attach the complete native stack trace? In the meantime, since I noticed you are using Java 21, could you also check if the same code fails for other LTS releases like 11 and 17?

PawanKartikS commented 8 months ago

Hi, I've tried out both Java 17 and Java 11 and the outcome is the same. Here's the error report: https://gist.github.com/PawanKartikS/d1522ea08ea6237444681d319a6887fa

dabico commented 8 months ago

Hi, I've tried out both Java 17 and Java 11 and the outcome is the same. Here's the error report: gist.github.com/PawanKartikS/d1522ea08ea6237444681d319a6887fa

Much obliged. Based on a cursory look, I noticed that you are running this from Scala. Is that correct? Could you provide more details about your project structure?

PawanKartikS commented 8 months ago

Sure! Here's what my project structure looks like:

src/main/scala/com.foo.bar/Main.scala
project/build.properties
build.sbt

Main.scala has the main method with just the System.load() call. Alternately, I created a standalone Main.java file with just the System.load() call and that failed as well.

Scala version: 3.4.0 Sbt version: 1.9.9

dabico commented 8 months ago

The library crashing when used in Scala through SBT is not all that surprising, given that it has not been tested with such a setup. The problem there could be that certain JDK classes that are pre-loaded on the native side are not available. This would explain the jni_GetFieldID SIGSEGV that you described in the issue. A class that JNI could not find is returned as a nullptr, which is then passed to the aforementioned field getter, leading to a segmentation fault.

What is concerning to me is that the Java file also fails for some reason. Can you also try this on a vanilla Maven project with just Java? We have some Java 11 libraries in our organization that depend on this, and we are unable to replicate your issue.

PawanKartikS commented 8 months ago

Just tried out a vanilla maven project and I'm getting the same error.

dabico commented 8 months ago

Screenshot 2024-03-04 at 14 15 01

After trying out different JDK releases myself locally, I can confirm that this is an issue that exclusively impacts M-series Macbooks. Unfortunately, I do not have one lying around to conduct a comparison. What's confusing to me is that the user who opened #101 managed to get it working after compiling it locally. But back to you...

Just tried out a vanilla maven project and I'm getting the same error.

Could you tell me if the error you observed in the vanilla Java project differs from the one you reported in the log?

PawanKartikS commented 8 months ago

Okay, I can confirm that this is an issue that is local to my machine. Resetting my environment and configuring things again from scratch including JDK (amongst others) fixed it.

Thank you for your time!

dabico commented 8 months ago

I'm glad you got it working in the end. I'm not sure how you planned to use this with Scala, but if you want to continue the conversation you are more than welcome to open a discussion. I'll close this for the time being.