Skip to content
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

Turn warnigns into errors in the test suite #187

Merged
merged 1 commit into from
Jun 7, 2017

Conversation

Carreau
Copy link
Contributor

@Carreau Carreau commented Jun 7, 2017

No description provided.

@Carreau
Copy link
Contributor Author

Carreau commented Jun 7, 2017

Hum apparently it's in core pytest since 2 weeks ago. Is that ok to require py.test >= 3.1 ?

@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

Requiring a new pytest is totally fine.

You might want to modify appveyor.yml as well.

@Carreau Carreau force-pushed the warnings-into-errors branch from bfd7f95 to 78500a8 Compare June 7, 2017 03:40
@codecov
Copy link

codecov bot commented Jun 7, 2017

Codecov Report

Merging #187 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #187   +/-   ##
=======================================
  Coverage   98.44%   98.44%           
=======================================
  Files          53       53           
  Lines        6129     6129           
  Branches      476      476           
=======================================
  Hits         6034     6034           
  Misses         80       80           
  Partials       15       15

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 496493a...78500a8. Read the comment docs.

@Carreau
Copy link
Contributor Author

Carreau commented Jun 7, 2017

Wooow. The travis job from my fork got a coredump, hopefully the PR is fine, but it's concerning.

@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

got a coredump

Umm. Wow. That is definitely a bit worrisome. Your link doesn't work for me, though... does it say anything useful?

(I have a suspicion it might be because ResourceWarning and Warning: coroutine '...' was never awaited run in a weird __del__ context and python might not be expecting exceptions here.)

@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

(I should say: specifically what I'm nervous of is that this might be a real bug in Python that we might hit again on random test runs depending on the phase of the moon etc. If so we need to figure it out and do whatever we have to to make sure it never happens again. Flaky tests are a constant issue for an I/O library like trio, so I'm super super vigilant about trying to keep them out. Anything else and you end up with like N different bugs that each causes a random test failure in 1/N times and it's unbearable.)

@Carreau
Copy link
Contributor Author

Carreau commented Jun 7, 2017

Link updated.
No nothing useful, as it's on travis I can't get it. Python 3.5.2:

collected 213 items 
�[0m
../../../../virtualenv/python3.5.2/lib/python3.5/site-packages/trio/_core/tests/test_epoll.py .
../../../../virtualenv/python3.5.2/lib/python3.5/site-packages/trio/_core/tests/test_io.py ..................................
../../../../virtualenv/python3.5.2/lib/python3.5/site-packages/trio/_core/tests/test_ki.py .........
../../../../virtualenv/python3.5.2/lib/python3.5/site-packages/trio/_core/tests/test_local.py ......
../../../../virtualenv/python3.5.2/lib/python3.5/site-packages/trio/_core/tests/test_multierror.py ...........
../../../../virtualenv/python3.5.2/lib/python3.5/site-packages/trio/_core/tests/test_parking_lot.py ....
../../../../virtualenv/python3.5.2/lib/python3.5/site-packages/trio/_core/tests/test_result.py ......
../../../../virtualenv/python3.5.2/lib/python3.5/site-packages/trio/_core/tests/test_run.py .....................................ci/travis.sh: line 55:  1366 Aborted                 (core dumped) pytest -W error -ra --run-slow ${INSTALLDIR} --cov="$INSTALLDIR" --cov-config=../.coveragerc

travis_time:end:003d71f4:start=1496806863236690128,finish=1496806912040002488,duration=48803312360
�[0K
�[31;1mThe command "ci/travis.sh" exited with 134.�[0m

@Carreau
Copy link
Contributor Author

Carreau commented Jun 7, 2017

And it does trigger on travis about every-other time, but apparently AFAICT only 3.5 and 3.5.2 are affected. Relaunch most of the jobs of this batch a couple of time and only 3.5. and 3.5.2 got failures. So I'm tempted to say it's "fixed".

@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

If it's only 3.5 then that's great for the python devs, but not so helpful for us, since we do want to keep testing on 3.5 :-).

I left pytest -W error trio running in a loop for a while last night on my laptop using debian's version of 3.5, and couldn't reproduce.

I guess next step will be to figure out how to get a stack trace, or otherwise figure out where exactly it's crashing...

@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

Just getting a failing run with -v -s added might be informative. Especially if we can then compare against the same run but with -W always.

@Carreau
Copy link
Contributor Author

Carreau commented Jun 7, 2017

Just getting a failing run with -v -s added might be informative. Especially if we can then compare against the same run but with -W always.

I'll try to do that, and see fi I can bisect which test(s) create that.
I may attempt to run that using their docker image to reproduce this.

@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

I just built a copy of 3.5.0 locally, and the first time running ~/src/cpython/b/install/bin/pytest -W error -v trio got a segfault.

It seems to be in trio/_core/tests/test_run.py::test_error_in_run_loop, which is extremely suspicious because that's the one test we have that intentionally triggers a Warning: coroutine '...' was never awaited

@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

Misc/NEWS for 3.5.3 says:

  • Issue 27811: Fix a crash when a coroutine that has not been awaited is finalized with warnings-as-errors enabled.

njsmith added a commit to njsmith/trio that referenced this pull request Jun 7, 2017
In addition to cluttering up the test output now that pytest collects
and shows warnings, this causes segfaults on some CI builds when run
with -W error (see python-triogh-187).
@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

See gh-189

@Carreau
Copy link
Contributor Author

Carreau commented Jun 7, 2017

Ha, good catch thanks !

@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

We still need to come up with something for resource warnings and unawaited coroutine warnings (#169) – ironically these are the two types of warnings that this PR doesn't catch (because they're both generated from __del__ methods, so can't raise errors), and also the two types of warnings that we actually have in our test suite currently :-). But this is definitely helpful to make sure we don't accidentally add more warnings we weren't expecting. Thanks!

@Carreau
Copy link
Contributor Author

Carreau commented Jun 7, 2017

In my other PR, I do attach the un awaited coroutines to NonAwaitedCoroutine error; which does allow to catch the exception and potentially consume them. I can or maybe (should ?) extend it with a context manager that keep a ref to all non-awaited coroutines within it ?

@njsmith
Copy link
Member

njsmith commented Jun 7, 2017

Whoops, meant to merge this :-)

@njsmith njsmith merged commit c63a8b7 into python-trio:master Jun 7, 2017
@Carreau
Copy link
Contributor Author

Carreau commented Jun 7, 2017

Thanks.

@Carreau Carreau deleted the warnings-into-errors branch June 7, 2017 22:53
@njsmith
Copy link
Member

njsmith commented Jun 8, 2017

...wtf, somehow the segfault still happened after merging into master: https://travis-ci.org/python-trio/trio/builds/240581553

...ugh, yeah, I can reproduce locally too if I re-run it enough times. Apparently #189 didn't actually fix anything.

@njsmith
Copy link
Member

njsmith commented Jun 8, 2017

#190

@njsmith
Copy link
Member

njsmith commented Jun 8, 2017

Oh right, with all this I almost forgot. My rule is anyone whose PR gets merged gets offered a commit bit :-). Want one? You can participate as much or as little as you like.

@Carreau
Copy link
Contributor Author

Carreau commented Jun 9, 2017

Oh right, with all this I almost forgot. My rule is anyone whose PR gets merged gets offered a commit bit :-). Want one? You can participate as much or as little as you like.

Happily, that will force me to try to review a bit more code :-)
Side question not to open another issue, are you avoiding type hints on purpose, or by habits ?

@njsmith
Copy link
Member

njsmith commented Jun 9, 2017

Happily, that will force me to try to review a bit more code :-)

Well, if you put it that way... invitation sent ;-)

Side question not to open another issue, are you avoiding type hints on purpose, or by habits ?

I just haven't had a chance to look at them seriously yet and form an opinion. I'm certainly open to providing them if it would be useful.

A minor issue is that sphinxcontrib-trio might need to be taught to handle them in a way that keeps the docs looking good (python-trio/sphinxcontrib-trio#4), but I'm sure that's solvable and probably needs to happen anyway.

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.

2 participants