Opened 8 years ago
Closed 8 years ago
#729 closed defect (fixed)
Python3: memory leak
Reported by: | Sean Robinson | Owned by: | Richard Boulton |
---|---|---|---|
Priority: | normal | Milestone: | 1.4.1 |
Component: | Xapian-bindings (Python) | Version: | 1.4.0 |
Severity: | normal | Keywords: | memory leak |
Cc: | Blocked By: | ||
Blocking: | Operating System: | Linux |
Description
I may have found a memory leak in Xapian 1.3+ with Python3. This exhibits itself when multiple indexing runs are done back-to-back without exiting the indexing program. I have tested this under Valgrind and it reports lost memory.
Attachments (1)
Change History (2)
by , 8 years ago
Attachment: | xapian-memleak-test.tar.gz added |
---|
comment:1 by , 8 years ago
Milestone: | → 1.4.1 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Thanks for the report.
There's a leak in the code to convert a string from Python to C++, which I've fixed in [c53ba8acd4862057fbbe478025962ef089bd7a1f] on master and backported to RELEASE/1.4 in [ ca8b8416bb6d4609b5e801fcd7347209893333f8] (so this should be fixed in 1.4.1).
I now get:
==19170== definitely lost: 0 bytes in 0 blocks ==19170== indirectly lost: 0 bytes in 0 blocks ==19170== possibly lost: 4,576 bytes in 7 blocks ==19170== still reachable: 987,276 bytes in 900 blocks ==19170== suppressed: 87,615 bytes in 37 blocks
The "possibly lost" probably aren't actual leaks - that means there's a pointer into an allocated block, but not to the start of it - snowball's code does that for example, and I think some of the C++ STL does too.
tar.gz of files used to test under Valgrind