Skip to content

bpo-33622: Add checks for exceptions leaks in the garbage collector. #7126

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 3 commits into from
May 29, 2018

Conversation

serhiy-storchaka
Copy link
Member

@serhiy-storchaka serhiy-storchaka commented May 26, 2018

Failure in adding to gc.garbage is no longer fatal.

https://bugs.python.org/issue33622

Failure in adding to gc.garbage is no longer fatal.
@@ -663,8 +663,10 @@ handle_legacy_finalizers(PyGC_Head *finalizers, PyGC_Head *old)
PyObject *op = FROM_GC(gc);
Copy link
Member

Choose a reason for hiding this comment

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

Usually, when I start to add assert(!PyErr_Occurred()), I like to add the assertion at the function entry and exit. Here it would avoid to remove an exception, since you add PyErr_Clear(). Currently, it's non obvious that the function must not be called with an exception set. An assertion would make it obvious ;-)

}
else {
if ((clear = Py_TYPE(op)->tp_clear) != NULL) {
Py_INCREF(op);
clear(op);
(void) clear(op);
assert(!PyErr_Occurred());
Copy link
Member

Choose a reason for hiding this comment

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

You might put the assertion into clear().

Copy link
Member Author

Choose a reason for hiding this comment

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

clear is tp_clear. It is defined in user code.

Copy link
Member

Choose a reason for hiding this comment

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

Oh I see. In that case, the assertion is correct.

@@ -1127,6 +1137,7 @@ gc_collect_impl(PyObject *module, int generation)
n = 0; /* already collecting, don't do anything */
else {
_PyRuntime.gc.collecting = 1;
assert(!PyErr_Occurred());
Copy link
Member

Choose a reason for hiding this comment

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

Would it make sense to put the assertion inside collect_with_callback()? At the entry.

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

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

LGTM.

My comments are just minor suggestions. The current change is good, if you want to apply it as it is.

Copy link
Member Author

@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.

Thank you Victor! I hoped on your review.

}
else {
if ((clear = Py_TYPE(op)->tp_clear) != NULL) {
Py_INCREF(op);
clear(op);
(void) clear(op);
assert(!PyErr_Occurred());
Copy link
Member Author

Choose a reason for hiding this comment

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

clear is tp_clear. It is defined in user code.

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

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

The PR is now perfect :-D

Exception handling at the C level is hard :-( It's so easy to get it wrong (clear or replace the current exception by mistake). These assertions should help to detect such bugs earlier.

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

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

Still LGTM even with the latest change ;-)

@serhiy-storchaka
Copy link
Member Author

I have replaced the assertion with this check because I have found few cases in the stdlib (very unlikely) in which tp_clear() sets an exception. Currently this can lead to a crash. Cases in the stdlib should be fixed in separate issues, but there may be third-party code.

@serhiy-storchaka serhiy-storchaka merged commit c4653c9 into python:master May 29, 2018
@serhiy-storchaka serhiy-storchaka deleted the gc branch May 29, 2018 15:50
@vstinner
Copy link
Member

I have replaced the assertion with this check because I have found few cases in the stdlib (very unlikely) in which tp_clear() sets an exception. Currently this can lead to a crash.

Oh. It's a bug, right? Do you plan to open a new issue or write a fix for these bugs?

If the bug is "very unlikely" and the case is now handled properly (error logged into stderr), maybe it's fine.

@serhiy-storchaka
Copy link
Member Author

I have opened three new issues for three possible cases of exceptions in tp_clear.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
skip news type-feature A feature request or enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants