-
-
Notifications
You must be signed in to change notification settings - Fork 31k
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
gh-127586: properly restore blocked signals in resource_tracker.py #127587
gh-127586: properly restore blocked signals in resource_tracker.py #127587
Conversation
Using SIG_UNBLOCK to remove blocked "ignored signals" may accidentally cause side effects if the calling parent already had said signals blocked to begin with and did not intend to unblock them when creating a pool. Use SIG_SETMASK instead with the previous mask of blocked signals to restore the original blocked set.
85370c0
to
5e4797c
Compare
Misc/NEWS.d/next/Library/2024-12-03-20-28-08.gh-issue-127586.zgotYF.rst
Outdated
Show resolved
Hide resolved
That would be great. We generally require tests for all bugfixes. |
…gotYF.rst Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
perfect, thanks. I've added a blocked signals test for resource tracker which should cover the issue. One weird thing I've noticed is that on some of my build pipelines, I'm seeing random test failures for idlelib on macos-13, e.g. https://github.com/python/cpython/actions/runs/12301168597/job/34331141506?pr=127587. Some of the test failures appear similar to what was reported on #76152. Not sure if there is an implicit dependency between resource_tracker and those unit tests, that I broke, or if this is unrelated to my changes. I looked for a while but couldn't find any explanation. I also just don't know idlelib too well. |
Yeah, those don't look related. Sometimes we get intermittent failures on some tests, generally not because of a bug in the code but because of a missing platform constraint on that test. I'm not sure if you have permissions to rerun failed CI jobs, so tag me if it happens and I'll do it. |
pthread_sigmask is not available on some platforms Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
Thanks @stephen-hansen for the PR, and @gpshead for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13. |
….py (pythonGH-127587) * Correct pthread_sigmask in resource_tracker to restore old signals Using SIG_UNBLOCK to remove blocked "ignored signals" may accidentally cause side effects if the calling parent already had said signals blocked to begin with and did not intend to unblock them when creating a pool. Use SIG_SETMASK instead with the previous mask of blocked signals to restore the original blocked set. * Adding resource_tracker blocked signals test (cherry picked from commit 46006a1) Co-authored-by: Stephen Hansen <stephen.paul.hansen@gmail.com> Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>
Sorry, @stephen-hansen and @gpshead, I could not cleanly backport this to
|
GH-127973 is a backport of this pull request to the 3.13 branch. |
|
|
|
|
The next 3.14 alpha release is tomorrow and these tier 1 and 2 buildbot failures are blocking it: https://buildbot.python.org/#/release_status Do you have an idea how to fix it or shall we revert this for now? |
…_tracker.py (pythonGH-127587)" This reverts commit 46006a1.
Revert PR in case we need it: #127983 |
I swear that I'm a buildbot failure magnet 😄 |
Yeah, it looks like the cleanup test behavior might have changed. At first glance it looks like the previous behavior was that both semaphores would leak, guessing terminate() + wait() was immediate? Feels like it is now blocking on the subprocess, as name1 leaks as expected but name2 appears to be cleaned by its finalizer.. this feels correct to me but would appreciate if someone could confirm. Guessing the fix is to change the 1 expected output line but for now happy to revert this. I’m going to investigate this more tonight. |
thanks! |
….py (pythonGH-127587) * Correct pthread_sigmask in resource_tracker to restore old signals Using SIG_UNBLOCK to remove blocked "ignored signals" may accidentally cause side effects if the calling parent already had said signals blocked to begin with and did not intend to unblock them when creating a pool. Use SIG_SETMASK instead with the previous mask of blocked signals to restore the original blocked set. * Adding resource_tracker blocked signals test Co-authored-by: Peter Bierma <zintensitydev@gmail.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>
…_tracker.py (pythonGH-127587)" (python#127983) This reverts commit 46006a1.
Closes #127586. Instead of using SIG_UNBLOCK to undo the blocked "ignored signals" by resource_manager when creating a child process, we instead will save the blocked signal mask as it was prior to the call to SIG_BLOCK and restore from there using SIG_SETMASK. This has the intended effect of preserving the SIG_BLOCK on either SIGTERM or SIGINT if either was already blocked when entering this method in the parent thread. Existing behavior where either signal was not blocked prior to entering the resource tracker is still preserved since the SIG_SETMASK will undo the SIG_BLOCKs anyway if those signals were previously unblocked.
Please let me know if anything else is needed here, e.g. if a unit test is worthwhile here, I could take a stab tomorrow at writing one.
multiprocessing.Pool
does not properly restore blocked signals #127586