This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Memory leak in gdbmmodule
Type: resource usage Stage: resolved
Components: Extension Modules Versions: Python 3.3, Python 3.4
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: bkabrda, christian.heimes, jcea, vstinner
Priority: normal Keywords: patch

Created on 2013-07-08 12:57 by bkabrda, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
gdbm-len-leak-fix.patch bkabrda, 2013-07-08 12:57
Messages (3)
msg192647 - (view) Author: Bohuslav "Slavek" Kabrda (bkabrda) * Date: 2013-07-08 12:57
Function dbm_length from Modules/_gdbmmodule.c seems to be leaking memory. A simple reproducer:

import dbm

d ='spam', 'c')
d['x'] = '1'

The interesting part of valgrind output with --leak-check=full:

==3312== 1 bytes in 1 blocks are definitely lost in loss record 1 of 3,622
==3312==    at 0x4A06409: malloc (in /usr/lib64/valgrind/
==3312==    by 0x3A31A0349D: get_next_key (gdbmseq.c:72)
==3312==    by 0x3A31A03595: gdbm_nextkey (gdbmseq.c:126)
==3312==    by 0xDD74192: dbm_length (_gdbmmodule.c:104)
==3312==    by 0x3A2473F50B: builtin_len (bltinmodule.c:1293)
==3312==    by 0x3A247510D1: PyEval_EvalFrameEx (ceval.c:4080)
==3312==    by 0x3A24753758: PyEval_EvalCodeEx (ceval.c:3462)
==3312==    by 0x3A2475390A: PyEval_EvalCode (ceval.c:791)
==3312==    by 0x3A24773893: run_mod (pythonrun.c:1989)
==3312==    by 0x3A24775EE7: PyRun_FileExFlags (pythonrun.c:1945)
==3312==    by 0x3A24777000: PyRun_SimpleFileExFlags (pythonrun.c:1455)
==3312==    by 0x3A2478F72B: Py_Main (main.c:306)

It seems that the problem is in the loop here [1] - specifically, the last okey.dptr seems not to be freed (the loop is terminated when key.dptr is NULL, but okey.dptr is still pointing to something).
I'm attaching a supersimple patch that should fix this (unless I'm totally wrong about everything...)

msg192723 - (view) Author: Bohuslav "Slavek" Kabrda (bkabrda) * Date: 2013-07-09 07:00
I just tried rebuilding with my patch and running test suite + I did some manual testing and everything seems to work fine - and the memory leak is not there.
msg201218 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2013-10-25 07:27
The problem is already fixed in 3.3 and 3.4. Thank you nevertheless! :)
Date User Action Args
2022-04-11 14:57:47adminsetgithub: 62604
2013-10-25 07:27:47christian.heimessetstatus: open -> closed

nosy: + christian.heimes
messages: + msg201218

resolution: out of date
stage: patch review -> resolved
2013-07-17 03:35:42jceasetnosy: + jcea
2013-07-09 08:20:31christian.heimessetnosy: + vstinner
stage: patch review
type: resource usage

versions: + Python 3.4
2013-07-09 07:00:30bkabrdasetmessages: + msg192723
2013-07-08 12:57:13bkabrdacreate