2010/6/1 <sm...@gmx.net>: > Sorry, I wrote tp_alloc in last post, it should be always tp_dealloc: > > My tp_dealloc 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 tp_dealloc and later (after return of tp_dealloc) > 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
