Mmh. This is tricky for Windows. I don't have a Windows machine to know what happened there.

@chris-eibl I know you're on Windows, so could you help me there please?

Will have a closer look tomorrow

@chris-eibl I know you're on Windows, so could you help me there please?

Ups, really tricky on Windows. I've found two different issues:

Edit: Created#143327

importos,sysimportsubprocesscode="""import os, sysargs = [sys.executable, '-c', 'print(4711)']os.execve(args[0], args, {})"""cmd_line= [sys.executable,'-X','faulthandler','-c',code]env_1=os.environ.copy()env_2= {}env_2['SYSTEMROOT']=os.environ['SYSTEMROOT']proc=subprocess.Popen(cmd_line,stdin=subprocess.PIPE,stdout=subprocess.PIPE,stderr=subprocess.PIPE,env=env_1)withproc:try:out,err=proc.communicate()finally:proc.kill()subprocess._cleanup()print("rc",proc.returncode)print("out",out)print("err",err)

Oh, so the problem issubprocess but not my fix?

Secondly, theos.execv* family has problems with strings on Windows:

Edit: created#143328

importosimportsysargs= [sys.executable,'-c','print("hello from execve")']os.execve(args[0],args, {})

    print(hello from execve)                ^^^^SyntaxError: invalid syntax

    print('hello          ^SyntaxError: unterminated string literal (detected at line 1)

I haven't found these two things reported as issues, yet, I think I should create two new issues?

With the above in mind, changing your test slightly to:

args= [sys.executable,'-c',"print('hellofromexecve')"]os.execve(args[0],args,MyEnv())"""        env = {}        env['__cleanenv'] = True  # signal to assert_python not to do a copy                                  # of os.environ on its own        rc, out, _ = assert_python_ok('-c', code, **env)        self.assertEqual(rc, 0)        self.assertIn(b"hellofromexecve",out)

let's it pass for me. Without your fix applied, it will fail with an access violation, due to the UAF 🚀

I haven't found these two things reported as issues, yet, I think I should create two new issues?

Please do so and thank you for all this investigation!

Oh, Win x64 now almost green in CI like for me. Unfortunately, arm64 and Win32 still crash. I will look at Win32, do not have an Arm machine ...

Sorry, didn't want to also apply my suggestion - just suggest. Misclicked, hangover from yesterday ...

You're hijacking my code! 😨

Could the issue on Windows and general be caused by this:

        PyObject *keyval = PyUnicode_FromFormat("%U=%U", key2, val2);

You're hijacking my code! 😨

And already apologized. Misclicked. Sorry again.

arm64 and Win32 still crash

Win32 is green for me. I've run

python -m test.test_os.test_os ExecTests.test_execve_env_concurrent_mutation_with_fspath

5 times sucessfully ...

Considering#137934, I think we will, for now, just skip the test on Windows. If evenos.execve is buggy in plain C, then there is nothing we can do on our side.

I think we should debug what the environment passed toexecve (that is, afterparse_envlist) is called

Just for posterity: I can reproduce the crash for commit7b6e2db x64 ft locally. Right before the call of

Furthermore, they are identical in the x64 regular build. All the more hints that something is broken in Windows ucrt_wexec*e (#137934).

Great to hear!

Thanks@picnixz for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

GH-143398 is a backport of this pull request to the3.14 branch.

GH-143399 is a backport of this pull request to the3.13 branch.

Oh I broke some build bots:

/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64/build/build_oot/python: error while loading shared libraries: libpython3.15d.so.1.0: cannot open shared object file: No such file or directory

I don't know what happened here though but it looks like changing some environment wasn't the best. Maybe I should skip build bots? (I will take care of this failure tomorrow)

GH-143431 is a backport of this pull request to the3.13 branch.