Skip to content

bpo-36370: Check for PyErr_Occurred() after PyImport_GetModule(). (GH-12504) #12504

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 4 commits into from
Mar 25, 2019
Merged

bpo-36370: Check for PyErr_Occurred() after PyImport_GetModule(). (GH-12504) #12504

merged 4 commits into from
Mar 25, 2019

Conversation

skrah
Copy link
Contributor

@skrah skrah commented Mar 22, 2019

@skrah skrah requested a review from a team March 22, 2019 23:42
@skrah skrah changed the title bpo-36370: Check for PyErr_Occurred() after PyImport_GetModule(). bpo-36370: Check for PyErr_Occurred() after PyImport_GetModule(). (GH-12504) Mar 22, 2019
Copy link
Member

@serhiy-storchaka serhiy-storchaka left a comment

Choose a reason for hiding this comment

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

Check also calls of PyImport_GetModule() and _PyImport_GetModuleId() in other files.

@skrah
Copy link
Contributor Author

skrah commented Mar 23, 2019

Thanks for taking a look, I've added two more files. There's one additional place in ceval.c:import_from(). That function has other issues, so I'll write a separate PR.

@skrah
Copy link
Contributor Author

skrah commented Mar 23, 2019

Retracting the FUD about ceval.c:import_from(). I didn't realize that PyErr_SetImportError() checks both arguments for NULL.

This PR should be complete now.

@asmeurer
Copy link

I can confirm this fixes the crash I reported.

PyErr_Clear();
if (PyErr_Occurred()) {
/* unrecoverable error */
PyErr_Clear();
Copy link
Member

Choose a reason for hiding this comment

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

Should not we call PyErr_WriteUnraisable()?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe, I updated the PR now because it's used in other places as well.

But PyErr_WriteUnraisable() contains a lot of code that could fail again; I'd be more comfortable in general with PyErr_Clear() and a simple fprintf().

On the other hand, in this particular case (thread finalization) stack exhaustion shouldn't be a problem.

@serhiy-storchaka
Copy link
Member

I was amazed how fast you had found the cause of the original bug.

@brettcannon
Copy link
Member

@serhiy-storchaka did you want to commit this?

@serhiy-storchaka
Copy link
Member

@skrah can do this himself.

@skrah skrah merged commit 027b09c into python:master Mar 25, 2019
@skrah
Copy link
Contributor Author

skrah commented Mar 25, 2019

Thanks everyone for the reviews and thanks @asmeurer for testing!

@miss-islington
Copy link
Contributor

Thanks @skrah for the PR 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

@bedevere-bot
Copy link

GH-12539 is a backport of this pull request to the 3.7 branch.

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Mar 25, 2019
…honGH-12504)

(cherry picked from commit 027b09c)

Co-authored-by: Stefan Krah <skrah@bytereef.org>
@asmeurer
Copy link

Thank you for the quick fix on this.

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

Successfully merging this pull request may close these issues.

7 participants