Need some help in analyzing a mixed traceback #276
-
|
Using github.com/ebitengine/purego v0.7.1. The purpose of the attached Go code is to execute the JVM library libzip.so deflater from one byte array to another. This is a proof of concept. Good news: So far, so good. I was able to load 3 required libraries and execute a few functions.
However, when I attempt to execute one function (the actual deflater), I see this: I am not asking you to debug the attached program (main.go). I am looking for advice as to how one would diagnose what is going wrong in main.go or what am I supposed to gleam from the stack trace. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
|
For whatever it is worth, I had desk-checked. Also, here are the variable values going into the |
Beta Was this translation helpful? Give feedback.
-
|
First thanks for using purego. The stack trace is almost always going to be useless in these situations since the issue is most likely caused by a disagreement of where the library expects an argument and where purego puts it. This usually happens because the function you are calling was defined incorrectly in the RegisterFunc function. I would try the following to solve this issue:
Also I'm not sure I understand why you are using the jvm to call into libzip when you can just download the C libzip.so from there website: https://libzip.org/ and run it directly without a jvm |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your reply and suggestions. I agree that one should never use the Java library functions from Go to perform functions (E.g. zip). I am quite familiar with the POSIX libzip functions. And, a far better choice from Go would be to use one of the Go standard library functions such as compress/gzip. My partner (@platypusguy) and I are engaged in the development of a Go-language JVM (https://github.com/platypusguy/jacobin). The source code that I attached here was the start of a proof of concept to see if we could use purego as a toolset for calling the C-language native functions. Given the volume, the eventual facility we adopt must be table-driven. Sounds like pure torture? (: To date, most of the Jacobin compute work is handled in Go using a large switch structure in jvm/run.go, the key of which being the JVM operation code - see https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-6.html for documetation of the JVM instruction set. This approach is working quite well, in general. We currently have a test base of 155 Java programs of various applications (https://github.com/texadactyl/jacotest.go) and most of the individual test cases pass. Except for native functions (trapped and cause an abort in Jacobin), we are successful at mapping many of the Java class-method-signature functions in a generic wrapper function (jvm/gfunctionExec.go) back to to Go replacement functions using a few table-driven techniques, driven from the INVOKE* switch cases. To-date, this is how we have been avoiding some of the native functions. But, given the sheer volume of native functions (>1000) and their complex relationship to the JVM class code (many-to-many), we were hoping to avoid "boiling the ocean". I guess that we will be engaged in a sizable effort no matter what we do. I have been also looking at using CGO too although it does not readily facilitate a table-driven approach. The same might be said using purego; time will tell. We might have to continue our original generic wrapper approach in replacing Java library class code to avoid the native functions that are called within those classes. Thanks, again. All feedback is appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
Ahh that's super cool. Yeah totally go for it sounds like a useful project |
Beta Was this translation helpful? Give feedback.
-
|
I wrote a C-language equivalent and blew up in that too, the same JVM library function call, namely What's different? I am trying to deflate (compress, in normal English) a byte array. It turns out that byte arrays need help from some functions that are accessed via a vector stored in the primary JVM area that is represented with a pointer. The C calls look like this example: Needless to say, Go cannot support such a C-particuliar interface. I've also created that type of vectoring in C and Assembler. It makes local mods on the fly to a function fairly easy. That is also how hardware interrupts are generally implemented. Good stuff! Anyways, I just wanted to tell you that y'all are innocent! (: |
Beta Was this translation helpful? Give feedback.
I wrote a C-language equivalent and blew up in that too, the same JVM library function call, namely
Java_java_util_zip_Deflater_deflateBytesBytes. All the simpler function calls work just fine in C and Go with purego.What's different? I am trying to deflate (compress, in normal English) a byte array. It turns out that byte arrays need help from some functions that are accessed via a vector stored in the primary JVM area that is represented with a pointer. The C calls look like this example:
(*env)->SetByteArrayRegion(env, inputArray, 0, sizeof(input), (jbyte*)input);. There are several functions of the same form that are required to set up the input and extract the output for array-orien…