retrobits / son_of_hunkypunk

Automatically exported from code.google.com/p/hunkypunk
22 stars 8 forks source link

Developer needs help with C code, upgrading Git Interpreter from 1.2.8 to 1.3.0 onto 1.3.4 #36

Closed BroadcastGames closed 4 years ago

BroadcastGames commented 8 years ago

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.

BroadcastGames commented 8 years ago

Here is how to isolate the problem for anyone trying to help on this:

  1. Checkout the current code here from son_of_hunkpunk - test the advent.blb Glulx game - and do the game 'version' command and confirm you have the VM version 1.2.8 that right now is on this project.
  2. Drop in Git 1.3.0 source code into the jin/git/ folder, just replace the source files. This commit of git: https://github.com/DavidKinder/Git/commit/a43c6bd1f66777bae21d5ab9912b97af9b5b03a1 -- Compile with NDK 12b and put the resulting binary libs in the appropriate place and deploy your APK. Tests with a Glulx game, advent.blb has been mentioned here as working 100%. Test that git 1.3.0 works fine (it does for me). "version" command in the game should show the 1.3.0 VM version in output and that you updated the binaries.
  3. Drop in Git 1.3.4 source code into the jni/git/ folder. Repeat the NDK compile, APK, test game you did in step 2. You should experience a crash when starting the game.

I've found one single line to prevent the crash with version 1.3.4: TextBufferWindow.java line 1593, comment that out.

https://github.com/retrobits/son_of_hunkypunk/blob/master/app/src/main/java/org/andglkmod/glk/TextBufferWindow.java#L1593

 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.

BroadcastGames commented 8 years ago

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!

BroadcastGames commented 8 years ago

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
BroadcastGames commented 8 years ago

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...