Nikhil Patel added the comment:
I'd like to respectfully disagree with the suggestions/conclusions mentioned
here. I'll explain my reasoning and conclusions below.
First the short version - I'm fairly confident the leak actually has to do
with:
https://github.com/python/cpython/blob/master/Lib/test/test_tools/test_unparse.py#L282
my approach:
It was initially implied that we can begin to pinpoint the leak from within the
test_files() method in test_tools.test_unparse.DirectoryTestCase.
I ran the tests using the command:
python_d -m test -R 3:3 test_tools.test_unparse -m test_files
I had test_files() print the files selected in line 282 (and limited sample
size to 1).
Result:
(note: i shortened printed pathnames manually after the fact, as it printed the
absolute paths)
python_d -m test -R 3:3 test_tools.test_unparse -m test_files
Run tests sequentially
0:00:00 [1/1] test_tools.test_unparse
Testing cpython\Lib\test\test_spwd.py
beginning 6 repetitions
123456
Testing cpython\Lib\copy.py
.Testing cpython\Lib\test\test_isinstance.py
.Testing cpython\Lib\test\test_bytes.py
.Testing cpython\Lib\test\test_csv.py
.Testing cpython\Lib\test\test_dynamic.py
.Testing cpython\Lib\test\test_xml_etree.py
.
test_tools.test_unparse leaked [3, 0, 13] references, sum=16
test_tools.test_unparse leaked [6, 2, 4] memory blocks, sum=12
test_tools.test_unparse failed
1 test failed:
test_tools.test_unparse
Total duration: 4 sec
Tests result: FAILURE
Then I made a slight modification: I replaced random.sample(names,1) on line
282 with a list containing the absolute paths to each of those files it tested
in the run I described above. That means each of those files would be loaded,
compiled and their tests run 6 times.
Result:
python_d -m test -R 3:3 test_tools.test_unparse -m test_files
Run tests sequentially
0:00:00 [1/1] test_tools.test_unparse
beginning 6 repetitions
123456
..
1 test OK.
Total duration: 24 sec
Tests result: SUCCESS
Conclusion:
If the same source files are being read, compiled, and their tests run - with
different results - then I do not believe the leak can be associated with the
self.checkRoundTrip() method or the compile() method
I don't have an in-depth explanation why this is the case. But removing the
call to random.sample() fixes the issue, I am reasonably sure of it.
I presume to say this because I commented out lines 280-282 and instead I made
it instead iterate through subsets of size 50 using slicing (so names[:50] etc)
in line 284. I went through the entire set of files, 50 at a time. All ran
successfully.
--
nosy: +npatel
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30542>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
