glibc detected *** python: corrupted double-linked list

Gabriel Genellina gagsl-py2 at
Wed Feb 25 17:16:47 CET 2009

En Wed, 25 Feb 2009 13:51:20 -0200, Christian Meesters <meesters at>  

>>> I have a problem using my software on my 64bit laptop, after an update
>>> of my system. The same code still runs on 32bit Intel, but on my laptop
>>> I provoke the crash in the title. The crash is caused - as narrowed
>>> down by me - by returning a static PyObject from a C-extension
>>> function.
>> I think you got all the reference counts wrong, specially dummy1, dummy2
>> and r.
> Might be a good point, but can you give me a hint where to look
> specifically?

   /* parse the input arguments r & vectors */
   if (!PyArg_ParseTuple(args, "OO", &r, &py_vectors))
     return NULL;

   for (i=0; i < vsize; i++) {
     dummy_2 = PyList_GetItem(dummy_1, 0);

   /* copy all items from pofr to py_pofr to be returned */
   if (!(py_pofr = PyList_New(0)))  return NULL;
   for (i=0; i < rlen; i++) {
     dummy_1 = Py_BuildValue("i", pofr[i]);
     if (!dummy_1) return NULL;
     PyList_Append(py_pofr, dummy_1);

   /* reference counters to zero */

r is an argument, a borrowed reference; you can't Py_CLEAR it.
dummy_1 is decremented inside the loop, and again three lines below.
dummy_2 is used far above the final Py_CLEAR, and it comes from  
PyList_GetItem, which returns a borrowed reference - you can't decrement  
it either.
Also there are several "return NULL" that don't decrement active objects  
(like "if (!dummy_1)..." above)

Getting the reference count right is critical: if you err by +1, the  
object will never be destroyed (leaking memory). If you err by -1, the  
object will be still in use after it was destroyed.

Gabriel Genellina

More information about the Python-list mailing list