[issue29048] Coverage influence tests, make some of them fail

Changes by Brett Cannon : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: OK, for now. Let's disregard my idea that stderr is swallowed. At some point these test might have worked under coverage. I was more thinking to bisect cpython. Perhaps i can find a revision that works. Patrik Den 24 dec 2016 20:26 skrev "Ned Batchelder" : >

[issue29048] Coverage influence tests, make some of them fail

Ned Batchelder added the comment: I don't believe this is coverage.py's fault, so I don't have an answer to your question. There is no revision of coverage.py that *does* swallow stderr. Also, as you can see from the test output, it isn't swallowed, it's not being captured where it should be

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: @nedbat, do you know of a revision where coverage doesn't influence the tests? If so, which one? Perhaps i can perform a bisect search to find when this went bad. I'm testing the latest tip/head. So that's one part of the bisect. -- _

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: Sure, here you go. $ ./python ../coveragepy debug sys -- sys --- version: 4.3a0 coverage: ../coveragepy/coverage/__init__.py cover_dirs: /home/irina/patrik/coveragepy/cover

[issue29048] Coverage influence tests, make some of them fail

Ned Batchelder added the comment: Can you show the output of "coverage debug sys"? -- ___ Python tracker ___ ___ Python-bugs-list mail

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: I'd like to clarify that the file i just attached, no-stderr.diff, is in no way a suggestion for a fix. It's just my way of conveying what i see. -- ___ Python tracker ___

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: For clarity, this is what i get in the test_exceptions test when i've applied the attached diff. $ ./python -m test -v test_exceptions == CPython 3.7.0a0 (default:8e311f109b22, Dec 24 2016, 12:26:43) [GCC 5.4.0 20160609] == Linux-4.4.0-53-generic-x86_64-with

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: yes, I'm sure. i printed markings around where the text should have been. Patrik Den 24 dec 2016 17:37 skrev "Ned Batchelder" : > > Ned Batchelder added the comment: > > Are you sure the code that tried to print to stderr was even run? It's in > a __del__ meth

[issue29048] Coverage influence tests, make some of them fail

Ned Batchelder added the comment: Are you sure the code that tried to print to stderr was even run? It's in a __del__ method, which is notorious for being affected by surprising things. -- ___ Python tracker _

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: report doesn't contain any text when run under coverage. something made the text not appear... Patrik Den 24 dec 2016 16:39 skrev "Patrik Iselind" : > > Patrik Iselind added the comment: > > i use the latest code. perhaps something for introduced after 3.6? >

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: i use the latest code. perhaps something for introduced after 3.6? Patrik Den 24 dec 2016 13:51 skrev "Ned Batchelder" : > > Ned Batchelder added the comment: > > I doubt very very much that coverage.py is stealing stderr. Many many > test suites would have t

[issue29048] Coverage influence tests, make some of them fail

Ned Batchelder added the comment: I doubt very very much that coverage.py is stealing stderr. Many many test suites would have this problem if that were true. More likely is that somehow __del__ is not being invoked when you need it to be. I tried running the tests under coverage also, and d

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: I've been looking into test_exceptions, why it fails. The reason seems to be that when the tests are executed under coverage, then they get nothing on the line that says the following in test_unraisable(). ```python report = stderr.getvalue() ``` So coverage s

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: As an example, the difference for test_exceptions: $ ./python ../coveragepy run --pylib --source=exceptions Lib/test/regrtest.py test_exceptions Run tests sequentially 0:00:00 [1/1] test_exceptions Exception ignored in: .BrokenDel.__del__ of .BrokenDel object

[issue29048] Coverage influence tests, make some of them fail

Changes by Serhiy Storchaka : -- nosy: +nedbat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: The fixes for test_ssl and test_subprocess seem strange to me. All they do is sweep the messages under the rug. Then there is not really any point with the 'with' block, is there? Without coverage those tests passed so i cannot really see how this adds up. --

[issue29048] Coverage influence tests, make some of them fail

Patrik Iselind added the comment: Are the tests that altered the execution environment something to bother with at all? Perhaps something for another issue? -- ___ Python tracker __

[issue29048] Coverage influence tests, make some of them fail

Serhiy Storchaka added the comment: Following patch fixes failures in test_ssl and test_subprocess. -- keywords: +patch nosy: +serhiy.storchaka stage: -> patch review Added file: http://bugs.python.org/file45998/coverity-tests-warnings.patch ___ Pyth

[issue29048] Coverage influence tests, make some of them fail

R. David Murray added the comment: Ideally it should not, so these would be interesting bugs to investigate. -- nosy: +r.david.murray priority: normal -> low ___ Python tracker _

[issue29048] Coverage influence tests, make some of them fail

New submission from Patrik Iselind: I checkout the latest tip from scratch. When i run the tests i get the following results: % ./python -m test -j [...] 376 tests OK. 1 test altered the execution environment: test_site 27 tests skipped: test_bz2 test_ctypes test_curses test_dbm_gnu te