-
-
Notifications
You must be signed in to change notification settings - Fork 433
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
Nonsensical coverage result: covered line right after non-covered line #1598
Comments
Picking this up for the PyCon 2023 sprints. |
After trying to reproduce this in Windows Subsystem for Linux (Ubuntu 20.02 LTS, Python 3.8) using Coverage 7.2.2 and the python-websockets repository both on the given commit and the latest Because I was not able to get a certain group of tests to run locally. likely related to my unusual execution environment, I tried to reproduce this issue with the subset of tests affecting the lines mentioned.
The result is all tests pass and the lines which were not being marked in the original report are showing up as covered wihtin the HTML report. Additionally, the tests which were covered by |
Running with
|
Oh, yes, I've also hit this error ("pop from empty list") while running the test suite with coverage. I don't know if it's related. |
After a long session of testing and researching - I've arrived at the conclusion that the problem itself is caused by CPython update. The line seems to be covered correctly up to version ConclusionI believe that the issue is related to the CPython change from 3.10 to 3.11, but it seems like it does behave correctly in newer versions. I believe the issue is outdated and thus can be closed. @nedbat Related issues:
|
Together with @Newtoneiro, we've created a minimal reproduction codebox based on It turns out that this issue is most likely related to |
That's good new at least for me -- I only run coverage on the latest Python version so 3.12 saves me :-) |
Describe the bug
In the screenshot below, line 1364 is marked as not covered and line 1367 is marked as covered.
This cannot happen. The only way to get to line 1367 is by going through line 1364.
To Reproduce
Python version 3.11.2 (installed with pyenv on macOS)
Coverage version 7.2.2 with C extension
Output of `coverage debug sys`
-- sys ------------------------------------------------------- coverage_version: 7.2.2 coverage_module: /Users/myk/Desktop/venv/lib/python3.11/site-packages/coverage/__init__.py tracer: -none- CTracer: available plugins.file_tracers: -none- plugins.configurers: -none- plugins.context_switchers: -none- configs_attempted: .coveragerc setup.cfg tox.ini pyproject.toml configs_read: -none- config_file: None config_contents: -none- data_file: -none- python: 3.11.2 (main, Apr 2 2023, 07:49:19) [Clang 14.0.0 (clang-1400.0.29.202)] platform: macOS-13.1-arm64-arm-64bit implementation: CPython executable: /Users/myk/Desktop/venv/bin/python def_encoding: utf-8 fs_encoding: utf-8 pid: 85045 cwd: /Users/myk/Desktop path: /Users/myk/Desktop/venv/bin /Users/myk/.pyenv/versions/3.11.2/lib/python311.zip /Users/myk/.pyenv/versions/3.11.2/lib/python3.11 /Users/myk/.pyenv/versions/3.11.2/lib/python3.11/lib-dynload /Users/myk/Desktop/venv/lib/python3.11/site-packages environment: HOME = /Users/myk PYENV_SHELL = zsh command_line: /Users/myk/Desktop/venv/bin/coverage debug sys sqlite3_sqlite_version: 3.39.5 sqlite3_temp_store: 0 sqlite3_compile_options: ATOMIC_INTRINSICS=1, BUG_COMPATIBLE_20160819, CCCRYPT256, COMPILER=clang-14.0.0, DEFAULT_AUTOVACUUM, DEFAULT_CACHE_SIZE=2000, DEFAULT_CKPTFULLFSYNC, DEFAULT_FILE_FORMAT=4, DEFAULT_JOURNAL_SIZE_LIMIT=32768, DEFAULT_LOOKASIDE=1200,102, DEFAULT_MEMSTATUS=0, DEFAULT_MMAP_SIZE=0, DEFAULT_PAGE_SIZE=4096, DEFAULT_PCACHE_INITSZ=20, DEFAULT_RECURSIVE_TRIGGERS, DEFAULT_SECTOR_SIZE=4096, DEFAULT_SYNCHRONOUS=2, DEFAULT_WAL_AUTOCHECKPOINT=1000, DEFAULT_WAL_SYNCHRONOUS=1, DEFAULT_WORKER_THREADS=0, ENABLE_API_ARMOR, ENABLE_BYTECODE_VTAB, ENABLE_COLUMN_METADATA, ENABLE_DBSTAT_VTAB, ENABLE_FTS3, ENABLE_FTS3_PARENTHESIS, ENABLE_FTS3_TOKENIZER, ENABLE_FTS4, ENABLE_FTS5, ENABLE_LOCKING_STYLE=1, ENABLE_NORMALIZE, ENABLE_PREUPDATE_HOOK, ENABLE_RTREE, ENABLE_SESSION, ENABLE_SNAPSHOT, ENABLE_SQLLOG, ENABLE_STMT_SCANSTATUS, ENABLE_UNKNOWN_SQL_FUNCTION, ENABLE_UPDATE_DELETE_LIMIT, HAS_CODEC_RESTRICTED, HAVE_ISNAN, MALLOC_SOFT_LIMIT=1024, MAX_ATTACHED=10, MAX_COLUMN=2000, MAX_COMPOUND_SELECT=500, MAX_DEFAULT_PAGE_SIZE=8192, MAX_EXPR_DEPTH=1000, MAX_FUNCTION_ARG=127, MAX_LENGTH=2147483645, MAX_LIKE_PATTERN_LENGTH=50000, MAX_MMAP_SIZE=1073741824, MAX_PAGE_COUNT=1073741823, MAX_PAGE_SIZE=65536, MAX_SQL_LENGTH=1000000000, MAX_TRIGGER_DEPTH=1000, MAX_VARIABLE_NUMBER=500000, MAX_VDBE_OP=250000000, MAX_WORKER_THREADS=8, MUTEX_UNFAIR, OMIT_AUTORESET, OMIT_LOAD_EXTENSION, STMTJRNL_SPILL=131072, SYSTEM_MALLOC, TEMP_STORE=1, THREADSAFE=2, USE_URIReproduction:
Then open the HTML coverage report for
src/websockets/legacy/protocol.py
and scroll to line 1364.This isn't a minimal example at all but at least it's reproducible.
Expected behavior
I expect the missing line to be marked as covered.
Indeed, it is exercised by:
tests.legacy.test_protocol.ClientTests.test_local_close_connection_lost_timeout_after_close
tests.legacy.test_protocol.ServerTests.test_local_close_connection_lost_timeout_after_close
If you change the missing line and raise an exception, these tests fail with that exception.
Additional context
You cannot reproduce the issue on the main branch because I chose to ignore the problem: python-websockets/websockets@901e434#diff-3851a087134dc94d4edce57e405054b17b85aed1639b8f62f1a79ba582345c3fR1365
If you look at this commit, you will also see another similar problem in the test suite. The lines marked as not executed are definitely executed; if you change them, tests fail.
The text was updated successfully, but these errors were encountered: