pyghidraRun not launching GUI

[bdemick]

TL;DR - Upgraded to 11.4, now pyghidraRun will only launch the GUI in some directories, chiefly my user $HOME, but this also happens in other directories, for seemingly no rhyme or reason. Terminal output does not indicate any errors or return a failure code. Doesn't matter if using absolute or relative path, as far as I can tell. This is on macOS 15.5.

GHIDRA_INSTALL_DIR is set, and it, as well as the support directory are in my system's path. I can run pyghidraRun from anywhere just fine, but it will only launch the GUI in the aforementioned circumstances. I rolled back to 11.3.2, and now observe this behavior for that version as well.

Things that I've tried:

1. Standalone and "built-in" venv PyGhidra installation methods - no change
2. Blew away ~/.ghidra folder, thinking maybe something weird had gotten cached - no change

What else can I try here?

[astrelsky]

Hmm, any chance this could be it?

ghidra/Ghidra/RuntimeScripts/Linux/support/pyghidraRun

Lines 7 to 10 in 7482131

	# Resolve symbolic link if present and get the directory this script lives in.
	# NOTE: "readlink -f" is best but works on Linux only, "readlink" will only work if your PWD
	# contains the link you are calling (which is the best we can do on macOS), and the "echo" is the
	# fallback, which doesn't attempt to do anything with links.

[bdemick]

I don't think so. The pyghidra_launcher.py script is being executed just fine. At the very least the SCRIPT_DIR and INSTALL_DIR variables appear to be correct.

[ryanmkurtz]

I won't have the opportunity to look into it until next week, but will do so as soon as possible.

[ReversingWithMe]

From my local testing with MacOS 15.5, is there any chance your venv or environment has a bad install of pyghidra, or is it possible having GHIDRA_INSTALL_DIR not set for me is helping?

I was mainly curious if there was something special about 11.4's pyghidra, and wanted to remove those variables.

Both commands launched from ~/

Ghidra 11.3.2, which was my current system path ghidra

pyghidrarun

Last used Python executable: ['~me/Library/ghidra/ghidra_11.3.2_PUBLIC/venv/bin/python3']
Using Python command: "~me/Library/ghidra/ghidra_11.3.2_PUBLIC/venv/bin/python3"
Switching to Ghidra virtual environment: ~me/Library/ghidra/ghidra_11.3.2_PUBLIC/venv
Name: pyghidra
Version: 2.1.0
Summary: Native CPython for Ghidra
Home-page:
Author:
Author-email: DC3 <[email protected]>
License: Apache-2.0
Location: ~me/Library/ghidra/ghidra_11.3.2_PUBLIC/venv/lib/python3.13/site-packages
Requires: Jpype1, packaging
Required-by:

Launches GUI

Downloading and unzipping 11.4

echo $GHIDRA_INSTALL_DIR
echo $PATH

...:<pathtoghidra>/ghidra_11.4_PUBLIC/support

pyghidrarun

Using Python command: "python3.13"
Do you wish to install PyGhidra (y/n)? y
Install into new Ghidra virtual environment (y/n)? y
Creating Ghidra virtual environment at ~me/Library/ghidra/ghidra_11.4_PUBLIC/venv...
Switching to Ghidra virtual environment: ~me/Library/ghidra/ghidra_11.4_PUBLIC/venv
Looking in links: ~me/Tools/Ghidra/ghidra_11.4_PUBLIC/Ghidra/Features/PyGhidra/pypkg/dist
Processing pathtoghidra/ghidra_11.4_PUBLIC/Ghidra/Features/PyGhidra/pypkg/dist/pyghidra-2.2.0-py3-none-any.whl
Processing pathtoghidra/ghidra_11.4_PUBLIC/Ghidra/Features/PyGhidra/pypkg/dist/jpype1-1.5.2-cp313-cp313-macosx_10_13_universal2.whl (from pyghidra)
Processing pathtoghidra/ghidra_11.4_PUBLIC/Ghidra/Features/PyGhidra/pypkg/dist/packaging-23.2-py3-none-any.whl (from pyghidra)
Installing collected packages: packaging, Jpype1, pyghidra
Successfully installed Jpype1-1.5.2 packaging-23.2 pyghidra-2.2.0

Launches GUI

An additional test from ~/

echo $GHIDRA_INSTALL_DIR
pathtoghidra/ghidra_11.4_PUBLIC
pyghidrarun

Last used Python executable: ['~me/Library/ghidra/ghidra_11.4_PUBLIC/venv/bin/python3']
Using Python command: "~me/Library/ghidra/ghidra_11.4_PUBLIC/venv/bin/python3"
Switching to Ghidra virtual environment: ~me/Library/ghidra/ghidra_11.4_PUBLIC/venv
Name: pyghidra
Version: 2.2.0
Summary: Native CPython for Ghidra
Home-page:
Author:
Author-email: DC3 <[email protected]>
License: Apache-2.0
Location: ~me/Library/ghidra/ghidra_11.4_PUBLIC/venv/lib/python3.13/site-packages
Requires: Jpype1, packaging
Required-by:

[ReversingWithMe]

Maybe try blowing away ghidra_11.4_PUBLIC/venv and see if that would help, or move it?

[ReversingWithMe]

Also in your path, is 11.4 the only ghidrahome/support you have?

echo $PATH | grep -i ghidra

[bdemick]

Poking at this some more things morning, I think the culprit is that for some reason, it will not launch the GUI within some directories, one of them being $HOME, although it doesn't seem to be limited to that. So when I started testing 11.4, I had just opened a new terminal, set up a test venv, installed everything there, and was confused when pyghidraRun didn't launch the GUI. I have yet to uncover the direct culprit. One thing I did note is that when the GUI doesn't start, nothing from that run shows up in the application log, so it's not even getting that far.

I did attempt to run pyghidra_launcher.py directly in a debugger, but the subprocess.Popen call fails with a maximum recursion depth exception, similar to #8190. Everything looked good up to that point, I think PyGhidra just really doesn't love being debugged or launched from a different context (or maybe I just haven't gotten the correct debug config to handle that).

Also tried blowing away the user settings directory ~/Library/ghidra/ghidra_11.4_PUBLIC folder and starting over, no change. About the only thing I haven't tried is to blow away the user temp and user cache folders, but the former is empty and the latter just looks to hold the javadocs and a packed-db-cache folder.

[astrelsky]

You definetely have something messed up, it's a matter of figuring out what. I've seen that pytest issue before but it wasn't with pyghidra and it was due to some import hook setting but I can't seem to find it or remember enough of what it was to find it.

Try running python with the -P option.

[bdemick]

No change, unfortunately.

[astrelsky]

Any chance it is a conflict between using free-threaded and non free-threaded? I had to hardcode the value in python_command.save in 3.13t of it silently does nothing when launched. It will either see pyghidra is installed and then start normal python where it isn't installed and silently fail, or vice-versa. Just figured I'd mention this possibility since I see you're using python 3.13 and for some reason when I initially installed python 3.13, the free-threaded one was the default (which is what I wanted, just wasn't expected).

[bdemick]

Wasn't quite sure how to check if that was enabled, at least wasn't indicated in the python3 -VV output. Instead I just tried in a Python 3.12 environment, and no change.

[astrelsky]

Wasn't quite sure how to check if that was enabled, at least wasn't indicated in the python3 -VV output. Instead I just tried in a Python 3.12 environment, and no change.

Ok, you usually have to explicitly run it unless py has it set as the default.

[ryanmkurtz]

2. Blew away ~/.ghidra folder, thinking maybe something weird had gotten cached - no change

FYI ~/.ghidra has not been used for several releases now. You probably want to blow away ~/Library/ghidra.

[bdemick]

You may be onto something with the presence of a folder named ghidra in the current directory being involved.

Made a test dir in my user home, cd into it, pyghidraRun launches GUI. Add a ghidra dir, and no GUI is launched. Remove ghidra, GUI launches.

I also noted that _GhidraBundleFinder.find_spec, where you suggested the sys.path log dump, does not seem to be run in cases where the GUI launches successfully.

[astrelsky]

So it sounds like the problem is in _GhidraBundleFinder then, at least the infinite recursion part.

[astrelsky]

Oh I think I know what it is, at least the infinite recursion, but unfortunately that's not the underlying issue here it's just hiding it.

The ghidra bundle finder is going to have to be careful about what java modules it imports to prevent this and may need to do some explicit accesses via sys.modules instead of import.

If it tries to import something, and it is not found, the import search will reach itself where it might again try the import and loop until overflow.

It can probably just be added later when everything it needs to import is guaranteed to be loaded.

[ryanmkurtz]

You may be onto something with the presence of a folder named ghidra in the current directory being involved.

Made a test dir in my user home, cd into it, pyghidraRun launches GUI. Add a ghidra dir, and no GUI is launched. Remove ghidra, GUI launches.

I also noted that _GhidraBundleFinder.find_spec, where you suggested the sys.path log dump, does not seem to be run in cases where the GUI launches successfully.

Ok, with this description I was able to reproduce it! I'll work on a fix. Thanks!

[ryanmkurtz]

Grabbed it this way:

with open('/Users/ben/stdout.log', 'w') as logfile:
    subprocess.Popen(py_args + remaining, creationflags=creation_flags, stdout=logfile, stderr=subprocess.STDOUT, text=True)

For future reference (even I forgot about this) you can run ./pyghidraRun --console to run it in the foreground, and then you'll see stderr/stdout.

[bdemick]

Oh awesome, thank you!

[ryanmkurtz]

Oh I think I know what it is, at least the infinite recursion, but unfortunately that's not the underlying issue here it's just hiding it.

The ghidra bundle finder is going to have to be careful about what java modules it imports to prevent this and may need to do some explicit accesses via sys.modules instead of import.

If it tries to import something, and it is not found, the import search will reach itself where it might again try the import and loop until overflow.

It can probably just be added later when everything it needs to import is guaranteed to be loaded.

There are problems even if the GhidraBundleFinder is commented out:

An error occurred launching Ghidra: cannot import name 'GhidraApplicationLayout' from 'ghidra' (unknown location)
Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "/Users/ryan/git/ghidra/Ghidra/Features/PyGhidra/src/main/py/src/pyghidra/ghidra_launch.py", line 118, in <module>
    launcher.start()
    ~~~~~~~~~~~~~~^^
  File "/Users/ryan/git/ghidra/Ghidra/Features/PyGhidra/src/main/py/src/pyghidra/launcher.py", line 515, in start
    self._report_fatal_error("An error occurred launching Ghidra", str(e), e)
    ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/ryan/git/ghidra/Ghidra/Features/PyGhidra/src/main/py/src/pyghidra/launcher.py", line 392, in _report_fatal_error
    raise cause
  File "/Users/ryan/git/ghidra/Ghidra/Features/PyGhidra/src/main/py/src/pyghidra/launcher.py", line 512, in start
    self._pre_launch_init()
    ~~~~~~~~~~~~~~~~~~~~~^^
  File "/Users/ryan/git/ghidra/Ghidra/Features/PyGhidra/src/main/py/src/pyghidra/launcher.py", line 445, in _pre_launch_init
    from ghidra import GhidraApplicationLayout
ImportError: cannot import name 'GhidraApplicationLayout' from 'ghidra' (unknown location)

[ryanmkurtz]

Seems like i can just remove the PWD from sys.path and everything works. You can also pass python -P to achieve this, but that's only supported in Python 3.11 and later (we stupport 3.9 and later currently).