Ghidrathon Incompatible with Python Threads

[mahaloz]

Hi there Ghidrathon team,

First, I want to say thank you for open-sourcing such a cool tool! It's awesome. I've tried a lot of Python3 -> Ghidra plugins, and this is an epic one. I found a limitation that I thought might be worth mentioning in your README. To preface, I have read the thread limitations section of the JEP project before submitting this.

Whenever you attempt to use the Ghidrathon Python3 interpreter from another Python thread, two critical problems happen:

1. JEP, which was used to make a single Java Interpreter flips out because a thread inside the interpreter is still alive after the main thread has died
2. All objects that used to be in the globals, as well as connected classes, are outdated.

To better demonstrate what I mean, here is a POC you can run:

from threading import Thread
import time

def loc_printer():
    i = 0 
    while i < 10: 
        i += 1
        time.sleep(1)
        print(f"Current location: {str(currentAddress)}") 

if __name__ == "__main__":
    t = Thread(target=loc_printer)
    t.daemon = True
    t.start()
    print("running thread!")

Place this code in a file and run it from the script manager. You will notice you get a scary-looking error from JEP:

2022-08-29 | 21:34:10 | ERROR | (ConsoleComponentProvider) Unexpected Exception: jep.JepException: All threads must be stopped before closing Jep. java.lang.RuntimeException: jep.JepException: All threads must be stopped before closing Jep.

You will also notice that the printed value of currentAddress never actually changes even if you click around your decompiler. This second bug is something I've tracked across a few projects, so I know its not something you can likely fix. It has something to do with the state passed through the Python interpreter.

Unfortunately, I come only bringing problems and no solutions :(. I thought it would be at least worth mentioning since it is unclear that Python threads will not work. In JEP docs, it seems as though having multiple Interpreter objects in Java would be the only issue, not having multiple threads in the Python Interpreter.

[mike-hunhoff]

@mahaloz thank you for mentioning this! We can update the documentation to reflect this limitation and possibly clean up the error thrown by Ghidrathon in case 1.

Some additional information on the errors you encountered:

1. JEP, which was used to make a single Java Interpreter flips out because a thread inside the interpreter is still alive after the main thread has died

This happens because we start a new Python interpreter for the script, run the code, and then immediately try to close the interpreter after the code has finished. As you demonstrated, if a rogue Python thread is left running Jep is going to throw an error.

2. All objects that used to be in the globals, as well as connected classes, are outdated.

We have limited opportunities to inject Ghidra state into the Python interpreter. For the Ghidraton interpreter, we inject state before each line of Python code is executed. For the Ghidra script manager (and Ghidra headless mode), we inject script state once before the Python script is executed. Therefore, any Python code running in between is going to see outdated data.