-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected traceback output in test_concurrent_futures and crash #109370
Comments
Simple
and
produce similar tracebacks, but without a crash. |
Surprisingly, it is 3.13-only issue. cc @vstinner |
Can you please give precise instructions on how to reproduce the issue? Should I patch Python? The command to reproduce the issue is |
There are two issues which may be related or not related:
Tracebacks are easy reproducible by running two tests. I did not try to reproduce the crash, because running all tests takes almost 40 minutes, and it may be order-depending. I ran full tests several times with other changes to libregrtest and found other crash, but not this one. I am not sure that my change to libregrtest was related. It was equivalent to the following patch: diff --git a/Lib/test/libregrtest/main.py b/Lib/test/libregrtest/main.py
index ba493ae179..98a98e4ea6 100644
--- a/Lib/test/libregrtest/main.py
+++ b/Lib/test/libregrtest/main.py
@@ -293,8 +293,6 @@ def run_tests_sequentially(self, runtests):
else:
tracer = None
- save_modules = sys.modules.keys()
-
jobs = runtests.get_jobs()
if jobs is not None:
tests = count(jobs, 'test')
@@ -317,11 +315,6 @@ def run_tests_sequentially(self, runtests):
result = self.run_test(test_name, runtests, tracer)
- # Unload the newly imported modules (best effort finalization)
- for module in sys.modules.keys():
- if module not in save_modules and module.startswith("test."):
- support.unload(module)
-
if result.must_stop(self.fail_fast, self.fail_env_changed):
break
diff --git a/Lib/test/libregrtest/single.py b/Lib/test/libregrtest/single.py
index de60566287..5c54419cfa 100644
--- a/Lib/test/libregrtest/single.py
+++ b/Lib/test/libregrtest/single.py
@@ -76,10 +76,6 @@ def _load_run_test(result: TestResult, runtests: RunTests) -> None:
# Load the test module and run the tests.
test_name = result.test_name
module_name = abs_module_name(test_name, runtests.test_dir)
-
- # Remove the module from sys.module to reload it if it was already imported
- sys.modules.pop(module_name, None)
-
test_mod = importlib.import_module(module_name)
if hasattr(test_mod, "test_main"): I.e. simply remove all removing of test modules before and after running a test. Actually, removing a module from |
I figured out what is wrong with tracebacks. They are triggered by closing the queue's writer connection in
|
Do you want to propose a fix for this? It may be a good start. |
…utures Follow-up of pythongh-107219. * Only close the connection writer on Windows. * Also use existing constant _winapi.ERROR_OPERATION_ABORTED instead of WSA_OPERATION_ABORTED.
…GH-109780) Follow-up of gh-107219. * Only close the connection writer on Windows. * Also use existing constant _winapi.ERROR_OPERATION_ABORTED instead of WSA_OPERATION_ABORTED.
…utures (pythonGH-109780) Follow-up of pythongh-107219. * Only close the connection writer on Windows. * Also use existing constant _winapi.ERROR_OPERATION_ABORTED instead of WSA_OPERATION_ABORTED. (cherry picked from commit 0b4e090) Co-authored-by: Serhiy Storchaka <[email protected]>
…futures (GH-109780) (GH-109882) Follow-up of gh-107219. * Only close the connection writer on Windows. * Also use existing constant _winapi.ERROR_OPERATION_ABORTED instead of WSA_OPERATION_ABORTED. (cherry picked from commit 0b4e090) Co-authored-by: Serhiy Storchaka <[email protected]>
…utures (pythonGH-109780) Follow-up of pythongh-107219. * Only close the connection writer on Windows. * Also use existing constant _winapi.ERROR_OPERATION_ABORTED instead of WSA_OPERATION_ABORTED.
…rrent_futures (pythonGH-109780) Follow-up of pythongh-107219. * Only close the connection writer on Windows. * Also use existing constant _winapi.ERROR_OPERATION_ABORTED instead of WSA_OPERATION_ABORTED. (cherry picked from commit 0b4e090) Co-authored-by: Serhiy Storchaka <[email protected]>
The superfluous output was fixed. As for the crash, it was difficult to reproduce. |
…ot concurrent.futures This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…current.futures (GH-114489) This was left out of the 3.12 backport for three related issues: - gh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - gh-109370 (which changes this to be only called on Windows) - gh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
…utures (pythonGH-109780) Follow-up of pythongh-107219. * Only close the connection writer on Windows. * Also use existing constant _winapi.ERROR_OPERATION_ABORTED instead of WSA_OPERATION_ABORTED.
…ot concurrent.futures (pythonGH-114489) This was left out of the 3.12 backport for three related issues: - pythongh-107219 (which adds `self.call_queue._writer.close()` to `_ExecutorManagerThread` in `concurrent.futures`) - pythongh-109370 (which changes this to be only called on Windows) - pythongh-109047 (which moves the call to `multiprocessing.Queue`'s `_terminate_broken`) Without this change, ProcessPoolExecutor sometimes hangs on Windows when a worker process is terminated. Co-authored-by: Victor Stinner <[email protected]> Co-authored-by: Serhiy Storchaka <[email protected]>
Crash report
When I run tests in single-process mode I get unexpected traceback output but tests was marked as passed:
Then Python crashed after reporting total success:
The last line is "Segfault (core dumped)" in Ukrainian, but I have no core dump because
ulimit -c
was 0.I ran tests with a modification of #108952 which does not remove test module or any imported during testing modules before or after running a test.
cc @vstinner
Linked PRs
The text was updated successfully, but these errors were encountered: