By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,050 Members | 1,019 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,050 IT Pros & Developers. It's quick & easy.

Custom type: PyObject_IS_GC access violation

P: n/a
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
Share this Question
Share on Google+
1 Reply


P: n/a
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.