Thanks to visit codestin.com
Credit goes to github.com

Skip to content

don't override non-Python signal handlers #16311

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

Merged
merged 2 commits into from
Jan 25, 2020
Merged

Conversation

stevengj
Copy link
Contributor

@stevengj stevengj commented Jan 23, 2020

The qt5 backend's mainloop() function (used by the non-interactive show()) calls signal(SIGINT, SIG_DFL) to temporarily override the SIGINT handler while the plot window is open. Unfortunately, this fails when Python has been embedded in another program and a non-Python signal handler is installed, as we encountered in Julia at JuliaPy/PyPlot.jl#459.

In particular, when signal.getsignal(SIGINT) returns None, this is documented to mean that "the previous signal handler was not installed from Python." In this case, you should not override the signal handler because there is no way to restore it — the signal(SIGINT, old_signal) function throws a TypeError if old_signal is None.

The fix is simple: don't try to override the SIGINT handler if old_signal is None.

Copy link
Contributor

@anntzer anntzer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

conditional on style fix and ci passing.

@tacaswell tacaswell modified the milestones: v3.1.3, v2.2.5 Jan 25, 2020
@tacaswell tacaswell merged commit d162b6d into matplotlib:master Jan 25, 2020
@lumberbot-app
Copy link

lumberbot-app bot commented Jan 25, 2020

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

  1. Checkout backport branch and update it.
$ git checkout v2.2.x
$ git pull
  1. Cherry pick the first parent branch of the this PR on top of the older branch:
$ git cherry-pick -m1 d162b6d2b8d001f893bc7a0a073f77f3ff445847
  1. You will likely have some merge/cherry-pick conflict here, fix them and commit:
$ git commit -am "Backport PR #16311: don't override non-Python signal handlers"
  1. Push to a named branch :
git push YOURFORK v2.2.x:auto-backport-of-pr-16311-on-v2.2.x
  1. Create a PR against branch v2.2.x, I would have named this PR:

"Backport PR #16311 on branch v2.2.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.

@tacaswell
Copy link
Member

The 2.2.x branch does not have the restoring logic, rather than implicitly backport that as well, only push this back to 3.1.x

@tacaswell
Copy link
Member

Thanks @stevengj ! Congratulations on your first merged Matplotlib pull request 🎉 Hopefully we will hear from you again.

timhoffm added a commit that referenced this pull request Jan 25, 2020
…311-on-v3.1.x

Backport PR #16311 on branch v3.1.x (don't override non-Python signal handlers)
timhoffm added a commit that referenced this pull request Jan 25, 2020
…311-on-v3.2.x

Backport PR #16311 on branch v3.2.x (don't override non-Python signal handlers)
@stevengj stevengj deleted the patch-1 branch January 25, 2020 14:13
@timjim333
Copy link

timjim333 commented Jan 25, 2020

Hi, I had a similar issue that only appeared when I ran Matplolib from Paraview's pvpython - is this fix something that I can implement or do I have to wait for the next release on conda? Thanks and regards. Tim

Edit: I just applied the 2-line fix detailed in the link at the top of the page manually in my conda-managed file:
~/anaconda3/envs/sound6/lib/python3.7/site-packages/matplotlib/backends/backend_qt5.py

I'm not sure if this is the best idea or not, but it fixes the issue for the moment!

@timjim333
Copy link

Sorry, just to add an additional comment (I know you've already sent off the patch) - would it be a little more robust to check if old_signal is not None? I realise that in this case, the non-None returns of signal.getsignal(SIGINT) (signal.SIG_IGN and signal.SIG_DFL) both currently evaluate to Python 'truthy', so that just if old_signal works at the moment, but would this in some foreseeable circumstance change? Not a criticism but a question, as I'm not well versed in these libraries! Thanks for the fixes!

@stevengj
Copy link
Contributor Author

From my understanding of the Python docs, any valid signal handler will have a True truth value. is not None would be fine too, of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants