[capi-sig] An unexpected visit_decref assertion violation (code works with 2.4, not with 2.5)

Campbell Barton ideasman42 at gmail.com
Fri May 1 04:29:15 CEST 2009

Hi Joe,
Start off by saying I don't know the answer to your problem, but will
try give some hints.
Unless anyone else has encountered this problem you could also mail
the python dev's about this too since they are more likely to know
about changes in pythons internals.
Though with obscure changes in python I have found your usually on your own :|
You might better pinpoint the cause of the problem by building python
from svn and finding the revision that broke it.

For doing any py/C api work I find it essential to build my own python
and keep the source in the build dir so I can step through python
the configure flag for debugging didnt work well for me either so I build wth
 ./configure --prefix=/opt/python/ --with-pydebug
 make CFLAGS="-O0 -g3 -fno-inline"; make install

Maybe this is obvious too but in gdb some useful commands when
stepping through pythons internals (where ob is a PyObject).
p *ob->ob_type
 ...lets you quickly see the type which can give you a hint as to whats going on
p PyObject_Print(ob, stderr, 0)

Should probably use gdb macro's but I have this function for quicker
printing, also means you dont have to check for NULL values before
printing (which will segfault).

void PyObSpit(char *name, PyObject *var) {
	fprintf(stderr, "<%s> : ", name);
	if (var==NULL) {
		fprintf(stderr, "<NIL>");
	else {
		PyObject_Print(var, stderr, 0);
	fprintf(stderr, "\n");

Interesting converting C++ to python, out of interest are you
inheriting the C++ class as a PyObject?
for Blender3D's game engine api I recently reworked some of the
python/C++ integration based on an API from 1997!
We have our own ref-counting going on, so this mixed with pythons
quite badly - now the PyObjects are member of the class which I find
more flexible.

On Thu, Apr 30, 2009 at 12:30 PM, Joe Ardent <jardent at ilm.com> wrote:
> Hello,
> I have a Python module here that takes a bunch of C++ classes, and turns
> them into Python classes.  When built against and loaded into Python 2.4,
> everything is fine.  But when built against and loaded into Python 2.5, I
> get an assert violation from Python's gc module.  Here is the code that is
> failing:
>    klass = PyClass_New(bases, classDict, className);
>    if (klass && methods) {
>        /* add methods to class */
>        for (def = methods; def->ml_name != NULL; def++) {
>            printf( "IlmPyClass: %d, def = %s\n", __LINE__, def->ml_name);
>            PyObject *func = IlmPyClass_NewFunction(def);
>            if (!func) {
>                Py_XDECREF(klass);
>                return NULL;
>            }
>            printf( "We get here\n" );
>            func = PyMethod_New(func, NULL, klass); //this line fails
>            printf( "We don't get here\n" );
>            # .......
>        }
>    }
> The output of 'python2.5 -c "import mymod"' is:
> """
> [.... snip a bunch of "we get here, we don't get here" etc. as things fail
> to fail...]
> IlmPyClass: 197, def = __init__
> We get here
> python2: Modules/gcmodule.c:276: visit_decref: Assertion `gc->gc.gc_refs !=
> 0' failed.
> Abort
> """
> The obvious things, such as Py_INCREFing klass or func, do not work.
> What's extra strange, in addition to this code working fine in an
> earlier python version, is that this code works fine for most of the
> classes that are instantiated.
> What I really want to do, though, is see what exactly is being decref'd.
>  Does anyone have any tips for doing this?  I've already tried using a debug
> build of Python; it doesn't seem to provide that type of ref tracing.
>  Thanks in advance for any tips or insights.
> --
> Joe Ardent
> _______________________________________________
> capi-sig mailing list
> capi-sig at python.org
> http://mail.python.org/mailman/listinfo/capi-sig

- Campbell

More information about the capi-sig mailing list