[New-bugs-announce] [issue18404] Memory leak in gdbmmodule

[Bohuslav "Slavek" Kabrda]

New submission from Bohuslav "Slavek" Kabrda:

Function dbm_length from Modules/_gdbmmodule.c seems to be leaking memory. A simple reproducer:

import dbm

d = dbm.open('spam', 'c')
d['x'] = '1'
print(len(d))


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/vgpreload_memcheck-amd64-linux.so)
==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...)


[1] http://hg.python.org/cpython/file/65f2c92ed079/Modules/_gdbmmodule.c#l102

----------
components: Extension Modules
files: gdbm-len-leak-fix.patch
keywords: patch
messages: 192647
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Memory leak in gdbmmodule
versions: Python 3.3
Added file: http://bugs.python.org/file30862/gdbm-len-leak-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18404>
_______________________________________