Skip to content

bpo-31285: fix an assertion failure and a SystemError in warnings.warn_explicit #3219

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

Conversation

orenmn
Copy link
Contributor

@orenmn orenmn commented Aug 27, 2017

  • in _warnings.c: add checks whether the return value of the received loader's get_source() is invalid.
  • in test_warnings/__init__.py: add tests to verify the assertion failure and the SystemError are no more.

https://bugs.python.org/issue31285

@@ -884,9 +884,9 @@ warnings_warn_explicit(PyObject *self, PyObject *args, PyObject *kwds)
}

/* Split the source into lines. */
source_list = PyObject_CallMethodObjArgs(source,
source_list = PyObject_CallMethodObjArgs((PyObject *)&PyUnicode_Type,
Copy link
Member

Choose a reason for hiding this comment

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

Use just PyUnicode_Splitlines().

return splitlines_ret_val
return BadSource()
return BadLoader()
self.assertRaises(IndexError, self.module.warn_explicit,
Copy link
Member

Choose a reason for hiding this comment

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

Since this test already takes multiple lines, I think it would look clearer if use a context manager form:

with self.assertRaises(IndexError):
     self.module.warn_explicit(...)

But why IndexError is expected? Wouldn't be better to test the normal case that doesn't raise an error? You can use test.support.captured_stderr() for capturing the warning output.

@@ -794,6 +794,33 @@ def test_stderr_none(self):
self.assertNotIn(b'Warning!', stderr)
self.assertNotIn(b'Error', stderr)

def test_warn_explicit(self):
Copy link
Member

Choose a reason for hiding this comment

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

This name is too general, but the test isn't a general test of warn_explicit(). Use something more specific like test_issue31285.

'foo', UserWarning, 'bar', 1,
module_globals={'__loader__': _get_bad_loader(42),
'__name__': 'foobar'})
self.assertIn('bar:1: UserWarning: foo', stderr.getvalue())
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am not sure whether this and the other call to assertIn() are necessary, as we want to make sure a SystemError and an assertion failure don't happen...

# warn_explicit() should neither raise a SystemError nor cause an
# assertion failure, in case the return value of get_source() has a
# bad splitlines() method.
def _get_bad_loader(splitlines_ret_val):
Copy link
Member

Choose a reason for hiding this comment

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

Starting underscore is not needed.

del self.module._showwarnmsg
with support.captured_stderr() as stderr:
self.module.warn_explicit(
'foo', ArithmeticError, 'bar', 1,
Copy link
Member

Choose a reason for hiding this comment

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

Is it valid to use ArithmeticError which is not a warning category?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is valid (IIUC, only warning.warns() requires the category to be a subclass of Warning). I used ArithmeticError because it caused get_filter() to return 'default'. But now it seems quite obscure to me, so I would change it.

Also, my test fails with -Werror, so I would fix that too.

@serhiy-storchaka serhiy-storchaka added needs backport to 2.7 type-bug An unexpected behavior, bug, or error labels Sep 24, 2017
@miss-islington
Copy link
Contributor

Thanks @orenmn for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 2.7, 3.6.
🐍🍒⛏🤖

@miss-islington
Copy link
Contributor

Sorry, @orenmn and @serhiy-storchaka, I could not cleanly backport this to 2.7 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 91fb0afe181986b48abfc6092dcca912b39de51d 2.7

@miss-islington
Copy link
Contributor

Thanks @orenmn for the PR, and @serhiy-storchaka for merging it 🌮🎉.. I'm working now to backport this PR to: 2.7, 3.6.
🐍🍒⛏🤖

@miss-islington
Copy link
Contributor

Sorry @orenmn and @serhiy-storchaka, I had trouble checking out the 3.6 backport branch.
Please backport using cherry_picker on command line.
cherry_picker 91fb0afe181986b48abfc6092dcca912b39de51d 3.6

@miss-islington
Copy link
Contributor

Sorry, @orenmn and @serhiy-storchaka, I could not cleanly backport this to 2.7 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 91fb0afe181986b48abfc6092dcca912b39de51d 2.7

serhiy-storchaka pushed a commit to serhiy-storchaka/cpython that referenced this pull request Sep 26, 2017
@bedevere-bot
Copy link

GH-3775 is a backport of this pull request to the 3.6 branch.

@bedevere-bot
Copy link

GH-3805 is a backport of this pull request to the 2.7 branch.

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Sep 29, 2017
serhiy-storchaka pushed a commit that referenced this pull request Sep 29, 2017
serhiy-storchaka pushed a commit that referenced this pull request Sep 29, 2017
orenmn added a commit to orenmn/cpython that referenced this pull request Sep 30, 2017
…) in case __loader__.get_source() has a bad splitlines() method. (pythonGH-3219)
serhiy-storchaka pushed a commit that referenced this pull request Sep 30, 2017
…) in case __loader__.get_source() has a bad splitlines() method. (GH-3219) (#3823)

(cherry picked from commit 91fb0af)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants