Antoine Pitrou added the comment:
See patch in issue 16628.
--
nosy: +pitrou
resolution: - duplicate
status: open - closed
superseder: - leak in ctypes.resize()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13091
New submission from Stefan Krah stefan-use...@bytereef.org:
Seen in test_multiprocessing:
==31662== 44 bytes in 1 blocks are definitely lost in loss record 687 of 10,548
==31662==at 0x4C2154B: malloc (vg_replace_malloc.c:236)
==31662==by 0x41CC27: PyMem_Malloc (object.c:1699)
==31662==
Changes by Meador Inge mead...@gmail.com:
--
components: +ctypes
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13091
___
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
How did you obtain this? the resize() function is not called by
test_multiprocessing.
And are you sure that it's not some kind of reference leak? (this pointer is
tied to a CDataObject; its tp_alloc should free the memory)
--
Meador Inge mead...@gmail.com added the comment:
I can reproduce this with:
valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full
--suppressions=Misc/valgrind-python.supp ./python -m test test_ctypes
Where as:
valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full
Meador Inge mead...@gmail.com added the comment:
this pointer is tied to a CDataObject; its tp_alloc should free the
memory
The free in 'PyCData_clear' is conditional:
if ((self-b_needsfree)
((size_t)dict-size sizeof(self-b_value)))
PyMem_Free(self-b_ptr);
As written,
