[petrasovaa]

This happened to me while using Claude to run tests, I am not entirely sure how important this is, on the other hand, it crashed my computer, so better to avoid this. Opening as draft because I didn't have time to scrutinize this very much myself.

get_install_path() could start grass --config path, which calls get_install_path(), which starts grass --config path again, without end. One wrong PYTHONPATH was enough to flood a machine with thousands of processes. The query now marks its child process so the child does not query again.

Details

Problem

The grass startup script reads its install prefix from grass.app.resource_paths. When that path does not exist, it calls get_install_path(), which tries the relative path and then, as a last resort, runs grass --config path and trusts the answer. If that executable is the same script in the same broken state, the sequence repeats, and every level is a new Python interpreter.

This happens with the source tree first on PYTHONPATH, since the placeholders in resource_paths.py are only substituted in the built copy. It is an easy mistake when testing uncommitted changes.

Change

get_install_path() sets GRASS_INSTALL_PATH_QUERY in the environment of the subprocess it starts. When the variable is already present, it skips all three executable queries (explicit path, GRASSBIN, grass on PATH) and returns the unresolved path, so the startup script fails with its normal error instead of recursing. No API change.

Test

A new test writes a fake grass executable that itself calls get_install_path() and asserts it runs exactly once. The fake refuses to go deeper than three levels, so a broken guard fails the test rather than flooding the system. Skipped on Windows because it relies on a shebang.

Written with assistance from Claude.