On Thu, 21 Feb 2002, David Abrahams wrote:
> The following extension module (AA) is a reduced example of what I'm doing
> to make extension
> classes in 2.2. I followed the examples given by typeobject.c. When I
> "import AA,pdb" I get a crash in GC. Investigating further, I see this makes
> sense: GC is enabled in class_metatype_object, yet class_type_object does
> not follow the first rule of objects whose type has GC enabled:
>
> "The memory for the object must be allocated using PyObject_GC_New()
> or PyObject_GC_VarNew()."
>
> So, I guess the question is, how does PyBaseObject_Type (also statically
> allocated) get away with it?
I doesn't have any time to really look at your code, but I thought I'd point
out a trick that several extension modules use to protect statically
allocated type objects. Here is the code from socketmodule.c:
/* static PyTypeObject PySocketSock_Type = {
.
.
.
0, /* set below */ /* tp_alloc */
PySocketSock_new, /* tp_new */
0, /* set below */ /* tp_free */
};
/* buried in init_socket */
PySocketSock_Type.tp_alloc = PyType_GenericAlloc;
PySocketSock_Type.tp_free = _PyObject_Del;
This trick ensures that the static type object is never freed.
Also, there is a funny-looking line in your PyTypeObject:
0, file://&PyBaseObject_Type, /* tp_base */
-Kevin
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com
Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
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