469,915 Members | 2,634 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,915 developers. It's quick & easy.

Custom type: PyObject_IS_GC access violation

I'm extending my C++ app by embedding Python 2.4.1 in it. The app is
multithreaded and split into several DLL's. The main EXE calls
Py_Initialize and Py_Finalize and each DLL gets a seperate interpreter
with Py_NewInterpreter.

The problem comes when I try to add a new type. I've been following the
"Extending and Embedding the Python Interpreter" tutorial. I've created a
PyTypeObject struct like so:

struct SA_PyVector {
PyObject_HEAD
int herman;
};

static PyTypeObject SA_PyVector_Type = {
PyObject_HEAD_INIT( 0 )
0,
"vector.Vector",
sizeof(SA_PyVector),
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
Py_TPFLAGS_DEFAULT,
"Vector objects",
};

But if I call

SA_PyVector_Type.tp_new = PyType_GenericNew;
PyType_Ready( &SA_PyVector_Type );

then, when Py_Finalize is called, PyObject_IS_GC(op) in visit_decref() in
gcmodule.c causes an access violation. If I don't call PyType_Ready, then
the access violation doesn't occure, but then the type can't be used...

So, the question is, does anyone have any idea about what could be
causing this?

/Bue
Jul 19 '05 #1
1 1702
Bue Krogh Vedel-Larsen wrote:
But if I call

SA_PyVector_Type.tp_new = PyType_GenericNew;
PyType_Ready( &SA_PyVector_Type );

then, when Py_Finalize is called, PyObject_IS_GC(op) in visit_decref() in
gcmodule.c causes an access violation. If I don't call PyType_Ready, then
the access violation doesn't occure, but then the type can't be used...

So, the question is, does anyone have any idea about what could be
causing this?


Most likely some code that you haven't shown. Here is the expansion
of PyObject_IS_GC(op)

#define PyObject_IS_GC(o) (PyType_IS_GC((o)->ob_type) && \
((o)->ob_type->tp_is_gc == NULL || (o)->ob_type->tp_is_gc(o)))

so it becomes

PyType_IS_GC(op->type) && (op->ob_type->tp_is_gc==NULL ||
op->ob_type->tp_is_gc(op))

Then, PyType_IS_GC(op->type) becomes

PyType_HasFeature((op->type), Py_TPFLAGS_HAVE_GC)

which in turn becomes

(op->tp_flags & Py_TPFLAGS_HAVE_GC) != 0

So typically, PyObject_IS_GC goes to the type of the object,
which should never crash, and then looks into the flags of
the type, which cannot crash - unless somebody messed with
ob_type of the object, and unless this isn't a Python
object in the first place.

You did not say what kind of object op was in the crash - this
is something you should investigate further. Does it point to
a Python object? If so, what is the type of the Python object?

Regards,
Martin
Jul 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.