Non utf8 output causes panic in interpreter discovery

Open Beginner friendly
#525 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python, rust
Domain
tooling

Research direction

Search the interpreter discovery code for String::from_utf8(...).unwrap() handling probed executable output. Update the output handling so non-UTF-8 stdout does not panic, then verify that discovery completes when a probe emits invalid UTF-8.

Written by the indexing model from the issue text.

Description

On some machines (as detected by Zed crash telemetry), toolchain discovery panics because a probed executable’s stdout is not valid UTF-8.

For example, we received:

b"\xCE\xC4\xBC\xFE\xB2\xBB\xB4\xE6\xD4\xDA: E:\\<redacted>\\-c\r\n"

This (according to my LLM) is GBK-encoding of 文件不存在: E:\<redacted>\-c, “File does not exist.”

I'm not sure why the executable appears to interpret -c as a filename, but I don't think we should panic on its output. Using String::from_utf8_lossy instead of String::from_utf8(...).unwrap() should address this.

Dominant language
Rust
Stars
207
Forks
45
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/python-environment-tools

All issues in microsoft/python-environment-tools

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.