2010/6/1 <smarv at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4