mirror of
https://github.com/espressif/esp-idf.git
synced 2026-05-28 16:46:31 +03:00
9bea09a081
Any idf.py invocation could hang indefinitely with no output while spawning an unbounded chain of "idf.py --version" subprocesses, eventually exhausting system memory. During init_cli(), idf.py parses the project's dependencies.lock to vet trusted component-provided idf_ext.py extensions. If the lock contains a component whose manifest has an "if: idf_version" clause, evaluating it calls idf-component-manager's _get_idf_version(). Outside a CMake build the IDF_VERSION environment variable is not set, so that function falls back to running "idf.py --version" as a subprocess, which re-enters init_cli() and recurses without bound. During a normal CMake build the component manager runs as a subprocess that already has IDF_VERSION in its environment (see build/config.env), so the fallback is never reached. The recursion happens only because idf.py runs component-manager code in-process during its own CLI startup, outside that context. Seed IDF_VERSION into os.environ early in init_cli(), before any dependencies.lock parsing, using the subprocess-free idf_version_from_cmake() helper. This gives in-process component-manager code the same IDF_VERSION a CMake build would provide.