Closed BroadcastGames closed 4 years ago
Here is how to isolate the problem for anyone trying to help on this:
I've found one single line to prevent the crash with version 1.3.4: TextBufferWindow.java line 1593, comment that out.
mLineEventBufferRock = retainVmArray(buffer, maxlen);
This will prevent input from getting from the Adventure game, it will act like you did not type anything into the game. But it does isolate the problem Java --> C interfacing between Git 1.3.0 and Git 1.3.4 and shows that the problem relates to the array being referenced by the param buffer when calling retainVmArray.
I'm still testing, but I think I have it narrowed down.
loader.c line 264 is a JNIEXPORT method in C that gets passed in a long variable of length. C declares the type as long and not jlong. https://github.com/retrobits/son_of_hunkypunk/blob/master/app/src/main/jni/loader/loader.c#L264
JNIEXPORT int Java_org_andglkmod_glk_Window_retainVmArray(JNIEnv *env, jobject this, int buffer, long length)
Adding a log print on line 265 of the length parameter value shows it is munged. I'll report back after more testing, but help is still welcome!
Oh yha, I defined a test method that is very revealing!
JNIEXPORT int Java_org_andglkmod_glk_Window_retainVmArrayTest(JNIEnv *env, jobject this, int buffer, jlong length, long lengthTwo)
{
LOGE("WTFBBQ? Java_org_andglkmod_glk_Window_retainVmArrayTest method length %d lengthTwo %d / alt %lu %lu / alt2 %llu %llu", length, lengthTwo, length, lengthTwo, length, lengthTwo);
return 0;
}
Add to Window.java:
protected native int retainVmArrayTest(int buffer, long length, long lengthTwo);
And here is the log output I get at runtime on a Nexus 6 running Android 7.0 (256 is passed in both times from a the identical Java long variable):
WTFBBQ? Java_org_andglkmod_glk_Window_retainVmArrayTest method length 256 lengthTwo 256 / alt 0 256 / alt2 256 12067396232331395328
My suggestion is that an experience C programmer here on the project look at this particular long jlong corruption and upgrade the Git interpret to 1.3.4 and commit that? I'm not enough of a 'clean' C programmer to offer a source code pull request...
I have only a rudimentary understanding of C, but I've been trying my best to understand this code, but I'm seriously stuck now.
First off, I know the Git interpreter isn't complete and is marked as a 'low-priority' enhancement. I'm not asking for help currently with finishing the incomplete features, I just want to update Git 1.2.8 to 1.3.4 in the Son of Hunkypunk andglk infrastructure.
Right now Son of Hunkypunk has Git 1.2.8. You can drop in the source code for Git 1.3.0 and everything works fine. But if you go beyond to Git 1.3.1 or to the latest 1.3.4, it crashes Son of Hunkypunk with array issues related to the Java LineInputEvent calls.
Git 1.3.4 has integrity checks and finds the arrays mismatched and aborts on line 1413 of glkop.c https://github.com/DavidKinder/Git/blob/master/glkop.c#L1413
I'm hoping an experienced C programmer can study the Git 1.3.0 to 1.3.4 changes and see what needs to be mended on the andglk data side of things. Thank you.
For reference: I'm using NDK 12b to compile all the interpreter code. I can upgrade and compile Git 1.3.4 with Twisty App fine and it works there, unmodified. So, this suggests the problem isn't in Git's c code but in the interface code inside Son of Hunkypunk.