You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I run coverage over Python's stdlib (this is directly, not using allcoverage since I forgot to use the script), I end up w/ nearly 34 GB of disk space used. Now I really doubt that the .coverage file is using that much space as it was not that big at the end of the run.
So my hunch is that there is a fundamental memory leak that is leading to a massive amount of swap being put on disk. This happens on both OS X Lion and OS X Snow Leopard. When I run the coverage again using the pure Python code then it never seems to trigger a use of disk (other than writing to .coverage).
Can you see where the disk space is going? There have been memory leaks in CTracer in the past, but not for a while, and others aren't reporting a problem. Perhaps fullcoverage torques it in some unusual way?
I'll see what I can do, but FYI fullcoverage was not used to trigger this; ./python.exe -m coverage --pylib Lib/test/regrtest.py.
And just to get as much info recorded as possible, the memory hit starts with test_argparse which (I think) is the first pure Python module to be tested. And this is against CPython default so it could be a bug in CPython itself. I also wonder if this might be Python 3 related as I assume hardly anyone uses coverage.py against Python 3 quite yet.
Originally reported by Brett Cannon (Bitbucket: brettcannon, GitHub: brettcannon)
When I run coverage over Python's stdlib (this is directly, not using allcoverage since I forgot to use the script), I end up w/ nearly 34 GB of disk space used. Now I really doubt that the .coverage file is using that much space as it was not that big at the end of the run.
So my hunch is that there is a fundamental memory leak that is leading to a massive amount of swap being put on disk. This happens on both OS X Lion and OS X Snow Leopard. When I run the coverage again using the pure Python code then it never seems to trigger a use of disk (other than writing to .coverage).
The text was updated successfully, but these errors were encountered: