Repository navigation
valgrind reports leaks for test_zipimport #67957
Description
| BPO | 23769 |
|---|---|
| Nosy | @vstinner, @serhiy-storchaka, @rkuska |
| Superseder | |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2022-01-28.02:41:02.724>
created_at = <Date 2015-03-24.22:32:14.240>
labels = ['tests']
title = 'valgrind reports leaks for test_zipimport'
updated_at = <Date 2022-01-28.02:41:02.723>
user = 'https://github.com/rkuska'bugs.python.org fields:
activity = <Date 2022-01-28.02:41:02.723>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2022-01-28.02:41:02.724>
closer = 'vstinner'
components = ['Tests']
creation = <Date 2015-03-24.22:32:14.240>
creator = 'rkuska'
dependencies = []
files = ['38672', '38673', '38675', '38684', '50594']
hgrepos = []
issue_num = 23769
keywords = []
message_count = 6.0
messages = ['239193', '239194', '239196', '239238', '325731', '411963']
nosy_count = 3.0
nosy_names = ['vstinner', 'serhiy.storchaka', 'rkuska']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '40077'
type = None
url = 'https://bugs.python.org/issue23769'
versions = ['Python 3.4']
Activity
rkuska commentedon Mar 24, 2015
Leaks happen only when both testDoctestFile and testDoctestSuite are run.
Run with Python 3.4.2 and 3.4.1 with same result.
I have extracted those two tests into
leak.py(attached).Note that when I remove support.modules_cleanup(*modules_before) from leak.py valgrind reports no leaks (in original test_zipimport those are run in setUp and tearDown).
Output of
valgrind --suppressions=/home/rkuska/upstream/cpython/Misc/valgrind-python.supp --leak-check=yes -v python3 leak.py
attached as
report.rkuska commentedon Mar 24, 2015
Summary for
valgrind python3 test_zipimport.py
==18608==
==18608== HEAP SUMMARY:
==18608== in use at exit: 1,596,390 bytes in 11,536 blocks
==18608== total heap usage: 343,849 allocs, 332,313 frees, 59,355,776 bytes allocated
==18608==
==18608== LEAK SUMMARY:
==18608== definitely lost: 90 bytes in 3 blocks
==18608== indirectly lost: 0 bytes in 0 blocks
==18608== possibly lost: 594,488 bytes in 2,258 blocks
==18608== still reachable: 1,001,812 bytes in 9,275 blocks
==18608== suppressed: 0 bytes in 0 blocks
==18608== Rerun with --leak-check=full to see details of leaked memory
==18608==
==18608== For counts of detected and suppressed errors, rerun with: -v
==18608== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
vstinner commentedon Mar 24, 2015
When calling gc.collect() after each test, I don't see any leak anymore.
doTest() has a small leak: it prepends a path to sys.path, but it never removes it.
Try attached leak2.py: it displays something like +254 kB. Uncomment the two following lines and the output will be close to +0 kB.
rkuska commentedon Mar 25, 2015
I tried leak2.py with valgrind, I've uncommented the lines you mentioned.
I've removed
import readlinefrom leak2.py, everything else left as in previous run (also ofc removed tracemalloc).Duh? Why does readline have this effect?
serhiy-storchaka commentedon Sep 19, 2018
zipimport has been rewritten in pure Python (bpo-25711).
vstinner commentedon Jan 28, 2022
It's not strictly a memory leak: running the same code multiple time doesn't leak memory. It's just that Python allocates memory once and never releases it (doesn't releast it at exit).
---
leak4.py: Updated and simplified script.
If the code is run 10 times, it doesn't leak. With 1, 10 or 100 loops (LOOPS=100), Python still says the same at exit:
Using cannot_deallocate2.patch of bpo-46417, I can see that multiple static types are not cleared at Python exit:
---
Cannot deallocate type 'Exception': it still has subclasses
Cannot deallocate type 'BaseException': it still has subclasses
Cannot deallocate type 'dict': it still has subclasses
Cannot deallocate type 'object': it still has subclasses
---
The _collections, itertools and _struct extensions implement types as static types which are not cleared at Python exit. It explains why Python says that there are still 664 memory blocks allocated at Python exit (664 blocks).
I consider that this issue is a duplicate of bpo-40077.