PyBytes_FromFormat() vs Py_BuildValue()

This is the place for queries that don't fit in any of the other categories.

PyBytes_FromFormat() vs Py_BuildValue()

Postby lash » Tue Sep 13, 2016 6:29 am

I struggled for a long time with segfaults and corrupted double linked list-issues in this code:

Code: Select all
unsigned int *pathindices = (unsigned int*)calloc(sizeof(unsigned int), steps * 2);
PyObject *path_final;

for (i = 0; i < steps; i++) {
    if (PyList_SetItem(path_final, i, PyBytes_FromFormat("%u", *(pathindices + i))) == -1) {

        PyErr_SetString(PyExc_RuntimeError, "Could not complete populating final path index array");
        if (pathindices != NULL)
            free(pathindices);
        return NULL;
    }
}

if (pathindices != NULL)
    free(pathindices)

return path_final


... until I changed PyBytes_FromFormat() to Py_BuildValues() which seemed to cure it (the routine has been running for nearly one hour now, crashed within max 1 minute before):

Code: Select all
for (i = 0; i < steps; i++) {
    if (PyList_SetItem(path_final, i, Py_BuildValue("I", *(pathindices + i))) == -1) {
    [...]
}


Although, if I removed free(pathindices) from the code, the routine using PyBytes_FromFormat() would run quite a bit longer, but of course ultimately fail because the memory was not being freed (I presume).

So, PyBytes_FromFormat() seems to be storing references to the pathindices memory, even if pathindices are passed by dereference to it in the argument (which should mean that it copies the value, right?).

According to the Python C extension docs, PyList_SetItem() should take over ownership of whatever is passed to it, and thus the caller to the this C function should ultimately in it's turn take over

What exactly is happening here, and what would "sane" usage of PyBytes_FromFormat() be?

(Using Python 3.4.3 [GCC 4.8.4] on linux)
lash
 
Posts: 4
Joined: Fri Sep 09, 2016 6:00 am

Return to General Coding Help

Who is online

Users browsing this forum: No registered users and 6 guests