[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Change by Jeremy Kloth : -- pull_requests: +30168 pull_request: https://github.com/python/cpython/pull/32081 ___ Python tracker ___

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Change by Jeremy Kloth : -- keywords: +patch pull_requests: +30167 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32079 ___ Python tracker ___

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

STINNER Victor added the comment: > It does seem that only the Windows Popen._wait() cannot handle negative > timeout values, so the fix should be as simple as coercing the timeout values > to >= 0. Oh. This function should maybe raise an exception if the timeout is negative, and ther

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Eryk Sun added the comment: > 4) use Job objects to group Windows processes for termination I think a separate issue should be created for this enhancement. _winapi wrappers would be needed for CreateJobObjectW(), SetInformationJobObject(), AssignProcessToJobObject(), TerminatejobObject(),

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Eryk Sun added the comment: > I fear the potential 3rd-party breakage alone should bump > this to its own issue. The change to the DWORD converter in _winapi should only be in 3.11+. If this causes problems for other projects, they're probably depending on undefined behavior in the standard

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Jeremy Kloth added the comment: > > the fix should be as simple as coercing the timeout values to >= 0. > > Popen._remaining_time() should return max(endtime - _time(), 0). That was my first initial instinct as well, however, that change would also affect more of the Popen behavior and need a

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Eryk Sun added the comment: > the fix should be as simple as coercing the timeout values to >= 0. Popen._remaining_time() should return max(endtime - _time(), 0). Popen._wait() should raise OverflowError if the timeout is too large for the implementation. In Windows, the upper limit in

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Jeremy Kloth added the comment: I've been able locally to reproduce the test_subprocess hang. The responsible function is subprocess.run(). The test case, test_timeout(), uses a small timeout value (0.0001), which, when given enough load, can cause the run() call to hang. A judicious use

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Eryk Sun added the comment: > test_call_timeout() or test_timeout() in test_subprocess.py. These tests don't override the standard files, and they only spawn a single child with no descendants. I don't see why this would hang. It shouldn't be a problem with leaked pipe handles (see

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Jeremy Kloth added the comment: The test only completed once I purposefully terminated the offending Python process. The only identifying information I noticed was the command-line of `-c "while True: pass"`, indicating it was stuck in either test_call_timeout() or test_timeout() in

[issue46716] regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x

Change by STINNER Victor : -- title: regrtest didn't respect the timeout on AMD64 Windows11 3.x -> regrtest didn't respect the timeout when running test_subprocess on AMD64 Windows11 3.x ___ Python tracker