[Python-Dev] tp_dealloc (original) (raw)

Amaury Forgeot d'Arc amauryfa at gmail.com
Tue Jun 1 11:52:44 CEST 2010

2010/6/1 <smarv at gmx.net>:

Sorry, I wrote tpalloc in last post, it should be always tpdealloc:

My tpdealloc method (of non-subtypable type) calls the freeMem-method of a memory manager (this manager was also used for the corresponding allocation). This freeMem-method deallocates and modifies the memory, which is a valid action, because after free, the memory-manager has ownership of the freed memory. Several memory managers do this (for example the Memory Manager in Delphi during debug mode, in order to track invalid memory access after free). The python31.dll calls tpdealloc and later (after return of tpdealloc) the python31.dll is still awaiting valid content in the deallocated memory. I don't know where this happens, I'm not a developer of CPython, but at this point the python31.dll causes an access violation. IMO the python31.dll assumes that freeMem never modifies the memory (pyobject header), this is valid for many memory managers, but not for all. And from my perspective, this assumption a bug, which can cause access violations in many applications (for example, applications which use the PythonForDelphi-package; PyScripter is one of them, but also many others) Please, could some CPython-developer take a look, thank you!

CPython does not access memory after the call to tp_dealloc. There is even a mode (--without-pymalloc) where tp_dealloc calls free() at the end, and would cause crashes if the memory was read afterwards.

This said, there may be a bug somewhere, but what do you want us to look at? Do you have a case that we could reproduce and investigate?

-- Amaury Forgeot d'Arc

More information about the Python-Dev mailing list